Re: [ovirt-devel] Validation issue with IntegerEntityModelTextBoxEditor
On 30/04/15 15:03, Tomas Jelinek wrote: - Original Message - From: Lior Vernia lver...@redhat.com To: Ramesh rnach...@redhat.com Cc: devel@ovirt.org Sent: Thursday, April 30, 2015 1:50:07 PM Subject: Re: [ovirt-devel] Validation issue with IntegerEntityModelTextBoxEditor I think it's an issue with other validations as well - we typically return true for frontend validations if the Object being validated is of the wrong type. In my opinion, it would be better to let a ClassCastException be thrown to allow developers see they're doing something wrong... but IFAIU this is a different issue - if you as a user type abc into a field which is allowed to have integer in it only, than the class cast exception is not a good thing to do. And since you have nothing better to return than null in this case, it is up to validation to tell that it is not correct. Right, correct, I was mixing two issues. But yeah, definitely we should have some generic error to say that this field is meant to contain integer numbers and not return a null Integer. On 30/04/15 14:38, Ramesh wrote: Hi, We have a validation issue with IntegerEntityModelTextBoxEditor. It converts non numeric values as null to the model. As a result IntegerValidation.validate() will be success always even in case of non integer value. Any suggestion to fix this issue?. Regards, Ramesh ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status
On 12/03/15 08:41, Ido Barkan wrote: 1187244 - 2, 3 work weeks I assume. we aim for 3.5.1. RHEV 3.5.1, so oVirt 3.5.2. It'll be tough to get it in RC2, but I think we'd still want it in the GA if we can get it fixed by then. - Original Message - From: Adam Litke ali...@redhat.com To: Sandro Bonazzola sbona...@redhat.com Cc: Amit Aviram aavi...@redhat.com, Yedidyah Bar David d...@redhat.com, Ido Barkan ibar...@redhat.com, Martin Perina mper...@redhat.com, Tal Nisan tni...@redhat.com, Maor Lipchuk mlipc...@redhat.com, Eyal Edri ee...@redhat.com, us...@ovirt.org, devel@ovirt.org Sent: Wednesday, March 11, 2015 3:09:43 PM Subject: Re: [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status On 11/03/15 13:33 +0100, Sandro Bonazzola wrote: Hi, We still have 8 open blockers for 3.5.2[1]: Bug ID Whiteboard Status Summary 1177220 storage ASSIGNED[BLOCKED] Failed to Delete First NFS snapshot with live merge Eric Blake is creating a workaround for libvirt. I just pinged him in the blocking bug https://bugzilla.redhat.com/show_bug.cgi?id=1199182 to check on his progress. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt Live 3.6 EL7 failing to start VMs
On 10/02/15 15:48, Sandro Bonazzola wrote:
Il 10/02/2015 13:38, Roy Golan ha scritto:
On 02/10/2015 02:07 PM, Sandro Bonazzola wrote:
Hi,
recently I rebased oVirt Live for 3.6 on EL7.
When I try to run a VM on it I have:
2015-02-10 12:10:00,523 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(ajp--127.0.0.1-8702-7) [376139c7] Lock Acquired to object 'EngineLock
[exclusiveLocks= key: ad476920-aafe-4af7-9f13-6ccbcd31f442 value: VM
, sharedLocks= ]'
2015-02-10 12:10:00,537 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(ajp--127.0.0.1-8702-7) [376139c7] START,
IsVmDuringInitiatingVDSCommand( vmId =
ad476920-aafe-4af7-9f13-6ccbcd31f442), log id: 6443d18a
2015-02-10 12:10:00,538 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(ajp--127.0.0.1-8702-7) [376139c7] FINISH,
IsVmDuringInitiatingVDSCommand, return: false, log id: 6443d18a
2015-02-10 12:10:00,546 WARN
[org.ovirt.engine.core.bll.scheduling.policyunits.NetworkPolicyUnit]
(ajp--127.0.0.1-8702-7) [376139c7] host local_host
is missing networks required by VM nics ovirtmgmt
2015-02-10 12:10:00,547 INFO
[org.ovirt.engine.core.bll.scheduling.SchedulingManager]
(ajp--127.0.0.1-8702-7) [376139c7] Candidate host 'local_host'
('3260585c-e7aa-4b1f-bc91-3dc72d15cbf8') was filtered out by
'VAR__FILTERTYPE__INTERNAL' filter 'Network' (correlation id: null)
2015-02-10 12:10:00,547 WARN [org.ovirt.engine.core.bll.RunVmCommand]
(ajp--127.0.0.1-8702-7) [376139c7] CanDoAction of action 'RunVm' failed for
user admin@internal. Reasons:
VAR__ACTION__RUN,VAR__TYPE__VM,SCHEDULING_ALL_HOSTS_FILTERED_OUT,VAR__FILTERTYPE__INTERNAL,$hostName
local_host,$filterName Network,$networkNames
ovirtmgmt,VAR__DETAIL__NETWORK_MISSING,SCHEDULING_HOST_FILTERED_REASON_WITH_DETAIL
2015-02-10 12:10:00,548 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(ajp--127.0.0.1-8702-7) [376139c7] Lock freed to object 'EngineLock
[exclusiveLocks= key: ad476920-aafe-4af7-9f13-6ccbcd31f442 value: VM
, sharedLocks= ]'
oVirt management network is there as it was in the el6 based iso, using a
dummy device and a vdsm hook for having it up.
what's the output of
http://localhost:8080/api/hosts/3260585c-e7aa-4b1f-bc91-3dc72d15cbf8/nics
Sorry, I had to reboot and since ovirt-live has no persistence I lost the
setup.
I've fully reproduced it, host id changed:
host_nics
actions
link
href=/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/setupnetworks
rel=setupnetworks/
/actions
host_nic
href=/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a
id=10070ac3-174a-4cf4-a774-8aed432a909a
actions
link
href=/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/attach
rel=attach/
link
href=/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/detach
rel=detach/
/actions
nameem1/name
link
href=/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/statistics
rel=statistics/
link
href=/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/labels
rel=labels/
host href=/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d
id=07915908-72ac-4fd9-8aef-e9dd3194981d/mac address=b8:ca:3a:76:9a:43/
ip address= netmask=/
boot_protocolnone/boot_protocol
statusstateup/state/status
mtu1500/mtu
bridgedfalse/bridged
/host_nic
/host_nics
[root@livecd ~]# ip addr
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: em1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether b8:ca:3a:76:9a:43 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global dynamic em1
valid_lft 85809sec preferred_lft 85809sec
inet6 fe80::baca:3aff:fe76:9a43/64 scope link
valid_lft forever preferred_lft forever
3: bond0: BROADCAST,MULTICAST,MASTER mtu 1500 qdisc noop state DOWN
link/ether ba:29:75:10:37:7e brd ff:ff:ff:ff:ff:ff
4: ovirtmgmt: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state
UNKNOWN
link/ether da:5a:78:93:ee:95 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global ovirtmgmt
valid_lft forever preferred_lft forever
inet6 fe80::d85a:78ff:fe93:ee95/64 scope link
valid_lft forever preferred_lft forever
5: ;vdsmdummy;: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
link/ether 2e:56:e6:64:38:3d brd ff:ff:ff:ff:ff:ff
# cat /etc/sysconfig/network-scripts/ifcfg-dummy0
DEVICE=dummy0
BRIDGE=ovirtmgmt
ONBOOT=yes
MTU=1500
NM_CONTROLLED=no
HOTPLUG=no
PROMISC=yes
# cat
Re: [ovirt-devel] oVirt Live 3.6 EL7 failing to start VMs
On 10/02/15 14:07, Sandro Bonazzola wrote:
Hi,
recently I rebased oVirt Live for 3.6 on EL7.
When I try to run a VM on it I have:
2015-02-10 12:10:00,523 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(ajp--127.0.0.1-8702-7) [376139c7] Lock Acquired to object 'EngineLock
[exclusiveLocks= key: ad476920-aafe-4af7-9f13-6ccbcd31f442 value: VM
, sharedLocks= ]'
2015-02-10 12:10:00,537 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(ajp--127.0.0.1-8702-7) [376139c7] START,
IsVmDuringInitiatingVDSCommand( vmId = ad476920-aafe-4af7-9f13-6ccbcd31f442),
log id: 6443d18a
2015-02-10 12:10:00,538 INFO
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand]
(ajp--127.0.0.1-8702-7) [376139c7] FINISH,
IsVmDuringInitiatingVDSCommand, return: false, log id: 6443d18a
2015-02-10 12:10:00,546 WARN
[org.ovirt.engine.core.bll.scheduling.policyunits.NetworkPolicyUnit]
(ajp--127.0.0.1-8702-7) [376139c7] host local_host
is missing networks required by VM nics ovirtmgmt
2015-02-10 12:10:00,547 INFO
[org.ovirt.engine.core.bll.scheduling.SchedulingManager]
(ajp--127.0.0.1-8702-7) [376139c7] Candidate host 'local_host'
('3260585c-e7aa-4b1f-bc91-3dc72d15cbf8') was filtered out by
'VAR__FILTERTYPE__INTERNAL' filter 'Network' (correlation id: null)
2015-02-10 12:10:00,547 WARN [org.ovirt.engine.core.bll.RunVmCommand]
(ajp--127.0.0.1-8702-7) [376139c7] CanDoAction of action 'RunVm' failed for
user admin@internal. Reasons:
VAR__ACTION__RUN,VAR__TYPE__VM,SCHEDULING_ALL_HOSTS_FILTERED_OUT,VAR__FILTERTYPE__INTERNAL,$hostName
local_host,$filterName Network,$networkNames
ovirtmgmt,VAR__DETAIL__NETWORK_MISSING,SCHEDULING_HOST_FILTERED_REASON_WITH_DETAIL
2015-02-10 12:10:00,548 INFO [org.ovirt.engine.core.bll.RunVmCommand]
(ajp--127.0.0.1-8702-7) [376139c7] Lock freed to object 'EngineLock
[exclusiveLocks= key: ad476920-aafe-4af7-9f13-6ccbcd31f442 value: VM
, sharedLocks= ]'
oVirt management network is there as it was in the el6 based iso, using a
dummy device and a vdsm hook for having it up.
Looks like the 'ovirtmgmt' bridge (correctly stated as the 'iface' for
network 'ovirtmgmt') doesn't have any 'ports', i.e. it's not connected
to any interface. I also don't see any dummy device reported as part of
the nics?...
# vdsClient -s 0 getVdsCaps
HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:86a8d0a8890'}]}
ISCSIInitiatorName = 'iqn.1994-05.com.redhat:86a8d0a8890'
autoNumaBalancing = 0
bondings = {'bond0': {'active_slave': '',
'addr': '',
'cfg': {'BOOTPROTO': 'none'},
'dhcpv4': False,
'dhcpv6': False,
'gateway': '',
'hwaddr': '52:87:0c:7c:59:e5',
'ipv4addrs': [],
'ipv6addrs': [],
'ipv6gateway': '::',
'mtu': '1500',
'netmask': '',
'opts': {},
'slaves': []}}
bridges = {'ovirtmgmt': {'addr': '10.0.0.1',
'cfg': {'BOOTPROTO': 'none',
'DEFROUTE': 'yes',
'DELAY': '0',
'DEVICE': 'ovirtmgmt',
'GATEWAY': '10.0.0.1',
'HOTPLUG': 'no',
'IPADDR': '10.0.0.1',
'MTU': '1500',
'NETMASK': '255.255.255.0',
'NM_CONTROLLED': 'no',
'ONBOOT': 'yes',
'STP': 'off',
'TYPE': 'Bridge'},
'dhcpv4': False,
'dhcpv6': False,
'gateway': '',
'ipv4addrs': ['10.0.0.1/24'],
'ipv6addrs': ['fe80::5811:41ff:fefd:f5a9/64'],
'ipv6gateway': '::',
'mtu': '1500',
'netmask': '255.255.255.0',
'opts': {'ageing_time': '3',
'bridge_id': '8000.',
'forward_delay': '0',
'gc_timer': '10583',
'group_addr': '1:80:c2:0:0:0',
'group_fwd_mask': '0x0',
'hash_elasticity': '4',
Re: [ovirt-devel] reporting and removing unmanaged networks after deprecating org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
On 02/02/15 14:21, Martin Mucha wrote:
Hi,
I'd like to discuss how to properly report unmanaged networks and how to ask
for their removal after
org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
is removed.
We don't actually have to remove the command, but I'd prefer not to
support two APIs at once (reminding that we'll be introducing new host
networking API in 3.6).
If I'm not mistaken, removing unmanaged networks is the only operation
the current design of the new API doesn't take care of... Right Moti?
We thought about several possibilities and so far the best one is following
one.
Reporting unmanaged networks on specific nic:
———
We'd like to return new collection under:
GET http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks
In my opinion it might be more convenient at part of
/api/hosts/{id}/unmanagednteworks - maybe going deeper isn't necessary.
returning (reporting) unmanaged networks like this:
unmanaged_networks
unmanaged_network
nic_name.../nic_name
unmanaged_network_name.../unmanaged_network_name
vland_id.../vland_id
/unmanaged_network
unmanaged_network
...
/unmanaged_network
/unmanaged_networks
Removing unmanagedNetworks:
—
DELETE
http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks/{unmanaged_network_name}
===
any ideas, hints, complaints, recommendations, confirmations are welcomed.
Martin.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 3.6 Feature: Cumulative Network Usage Statistics
On 28/01/15 14:20, Dan Kenigsberg wrote: On Tue, Jan 27, 2015 at 12:03:38PM +0200, Lior Vernia wrote: On 26/01/15 15:45, Dan Kenigsberg wrote: On Mon, Dec 22, 2014 at 01:40:06PM +0200, Lior Vernia wrote: Hello users and developers, Just put up a feature page for the aforementioned feature; in summary, to report total RX/TX statistics for hosts and VMs in oVirt. This has been requested several times on the users mailing list, and is especially useful for accounting in VDI deployments. You're more than welcome to review the feature page: http://www.ovirt.org/Features/Cumulative_RX_TX_Statistics Sorry for the late review; I have a couple of questions/comments. - What do you mean by VDI use cases in the Benefit to oVirt sanpshot section? Do you refer to hosting services who would like to charge their customers based on actual bandwidth usage? Indeed, as well as monitoring utilisation by non-paying users (say inside the same organization). Changed the wording a little, as hosting services are really the prime candidate. - I've added another motivation: currently-reported rxRate/txRate can be utterly meaningless. I don't see reference to nasty negative flows: what happens if a host disappears? Or a VM? I suppose there's always a chance that some traffic would go unaccounted for. But do you expect to extract this information somehow? Either way, it should be mentioned as a caveat on the feature page. What do you mean by disappears? Engine loses connectivity to it? I meant the case of, say, Engine going down while VMs continue to chug bandwidth. One of these VMs dies (say, the user shuts it down). When Engine wakes up, it would find the VM in Down state. I wonder if Vdsm should keep the last tx/rx used by this VM so Engine can collect it, and charge the VM properly. A similar case can occur if a host is rebooted while Engine was away. But there I see no way to keep trace of the unaccounted-for badwidth. This would require a double failure - first the engine losing connectivity to the host, then at a later point the host/VM shuts down. If the engine loses connectivity but the host/VMs remain operational, then as soon as the engine regains connectivity it'll be brought up to speed (traffic could be missed if the RX/TX counters on the host/VMs exactly wrapped around during that period, which is highly unlikely). If the host/VMs go down without the engine losing connectivity, the engine should continue to accumulate statistics correctly. So the problem isn't grave (though I'll document those cases in the feature page), and the solution won't be trivial. Would you really want vdsm to track this data? And then engine would have to collect it before a VM is run or a vNIC is hot-plugged?... ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [DB] Diffrent UUIDs for inserted data per installation
Apologies for the late response... On 25/01/15 13:44, Moti Asayag wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Sahina Bose sab...@redhat.com, Allon Mureinik amure...@redhat.com, Arik Hadas aha...@redhat.com, Mike Kolesnik mkole...@redhat.com, Gilad Chaplik gchap...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org Sent: Wednesday, January 21, 2015 6:05:51 PM Subject: [ovirt-devel] [DB] Diffrent UUIDs for inserted data per installation Hi I am trying to cleanup all the data insertion to the engine DB and make it more general The main drive to that is DB version squashing that was done manually and therefor was error prone ... I know that both storage_pool_id (a.k.a DC) and vds_group_id (a.k.a Cluster) needs to get a different UUID per installation. But I had found that UUIDs are generated per installation for also : table | column/s [cpu_profiles] : id [gluster_services] : id [mac_pools] : id Added Martin to comment on this one. AFAIK the id can be static for all installations. Looks okay to have a static ID for the default MAC pool. [permissions] : id, object_id [vm_device]: device_id, vm_id [vm_static] : vm_guid [vnic_profiles] : id Added Lior to comment. In any case, we can evaluate the id by querying by name, hence the specific value id value shouldn't be important. We don't need to have distinct IDs by installation, however the current upgrade script creating the IDs (03_03_0710) creates one for each existing network, and every deployment will have its own networks... If your change might affect upgrades from versions 3.3, then I don't see how you could achieve this using static IDs. Please let me know if any of the above should be generated using the uuid_generate_v1() function on each installation or we can have static IDs for those. Thanks Eli Mesika ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Move bugs to ON_QA based on snapshot builds?
On 28/01/15 11:53, Sven Kieske wrote: Hi, just a quick question: Would this imply that you need to create separate bugs to track these solved on master bugs for the next release? So you know the fix/feature really hit's the release? Or how would you track that? I would stop the automated moving to ON_QA from snapshot builds as soon as we create a stable ovirt-3.6 branch. At that point you know that any existing fix will really hit the release, and onwards only patches backported to the stable branch will be moved to ON_QA as stable branch releases are available (whether nightly, weekly, monthly). So no need for separate bugs. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Move bugs to ON_QA based on snapshot builds?
Hello everyone, I wanted to suggest that we automate the change of oVirt 3.6 bug status from MODIFIED to ON_QA based on nightly snapshot builds. The motivation should be clear: when bugs are fixed on the master branch, the fix becomes readily available for verification as soon as the next snapshot is built (and there's indeed someone to verify on the master branch - the same person who was working on the master branch and opened the bug!). We currently only move them to ON_QA on milestone builds (e.g. alpha, beta), but I don't think that's right for an open source project - the status of bugs (targeted to the nearest release) should be up-to-date with the actual state of the master branch. We've encountered the problem testing features for 3.6 the last couple of weeks, and since it's gonna be a long version this situation will likely occur often. So far I've been moving bugs to ON_QA myself, but I don't really want to follow the snapshot builds manually (nor move the bugs to ON_QA as soon as they're merged, in case the snapshot build doesn't happen). The downside would be that bugs could be VERIFIED at an early point in the development, and later regressions could occur that would render the verification obsolete. But this could happen just the same between release milestones... Thoughts? Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Adding support for 3.6 in engine database
On 14/01/15 17:27, Alon Bar-Lev wrote: - Original Message - From: Oved Ourfali ov...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org Sent: Wednesday, January 14, 2015 5:19:03 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org Sent: Wednesday, January 14, 2015 5:03:12 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database On Wed, Jan 14, 2015 at 08:19:00AM -0500, Oved Ourfali wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Oved Ourfali ov...@redhat.com, fsimo...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org Sent: Wednesday, January 14, 2015 3:15:02 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database On Thu, Jan 08, 2015 at 08:46:09AM -0500, Oved Ourfali wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Lior Vernia lver...@redhat.com, Oved Ourfali oourf...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg dan...@redhat.com, Yaniv Bronheim ybron...@redhat.com Sent: Thursday, January 8, 2015 3:41:31 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database - Original Message - From: Lior Vernia lver...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg dan...@redhat.com, Yaniv Bronheim ybron...@redhat.com Sent: Thursday, January 8, 2015 3:08:24 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database Tried to work with it, and noticed that: 1. The engine doesn't list 4.17 as a supported vdsm version. 2. 4.17 vdsm doesn't report 3.6 as a supported engine version. This basically means that no host could be operational in a 3.6 cluster, as to my understanding 4.17 is exactly the version supporting 3.6 functionality. May I send a fix for (1), or is there any argument against? And who could take care of (2)? I had understood deom Oved that this is 4.16 see patch http://gerrit.ovirt.org/#/c/36511/ Oved ??? I don't know when we should add 4.17. I remember there is some policy for that. Dan? Yes, there is. Vdsm would like to declare its support of clusterLevel 3.6 only when it actually does. This is not yet the case, as we are not yet in 3.6 feature freeze (heck, we're not yet in feature definition). To test cluster level 3.6 on the master branch, someone has to lie. It may be Vdsm (by claiming that it supports 3.6 while it does not) or Engine (by allowing vdsm 4.17 into cluster 3.6, even though it does not). I prefer the latter, as the Engine-side hack is eaiser to undo on a distributed system. If today's Vdsm claims that it already support 3.6, future Engines would add it to their cluster, only to find that random APIs fails. If the hack is Engine-side, it would be gone when 3.6 reaches feature freeze. We don't have a mechanism to allow specific version of VDSM to a specific cluster level. For this we only rely on the reported supported cluster levels. I know. I'm asking Engine to add it. The logic in the engine is complex and confusing enough, without adding any other configuration to it, so I prefer to leave it as is. I don't see why we can't add the cluster levels to the supported VDSM cluster levels, as we didn't release any official VDSM version yet, so what's the issue with that? The fact that engine master has 3.6 cluster level doesn't mean it is supported either. It will be once 3.6 is released. this is old discussion... if master work toward a release or version is determine near release. there are two policies in our project, one for vdsm - determine versions near release, and the other is to all other components which is working toward a release. I believe that working toward a release is a better approach especially when components are a coupled. The current state, where merged code can't be used, is definitely out of the question. Dan - sounds like Oved is against adding this temporary code (and you can understand why), and that Alon also supports early reporting of version compatibility. How strongly do you feel about your position? ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 13/01/15 10:18, Sahina Bose wrote: On 01/12/2015 06:21 PM, Lior Vernia wrote: Hi Sahina! :) Cool feature, and I think long-awaited by many users. I have a few comments: 1. In the Add Bricks dialog, it seems like the IP Address field is a list box - I presume the items contained there are all IP addresses configured on the host's interfaces. 1. a. May I suggest that this contain network names instead of IP addresses? Would be easier for users to think about things (they surely remember the meaning of network names, not necessarily of IP addresses). 1. b. If I correctly understood the mock-up, then configuring a Storage Network role only affects the default entry chosen in the list box. Is it really worth the trouble of implementing this added role? It's quite different than display/migration roles, which are used to determine what IP address to use at a later time (i.e. not when configuring the host), when a VM is run/migrated in the cluster. If not for Storage network role, how would we default which network to use. In fact, we are planning to remove the drop down to choose network from the Add Brick UI, to avoid confusion and just use the network with this role, if available - otherwise use the host address. (host_address in vds_static) If the list box goes, then yeah, somehow you'll have to mark the network used for gluster traffic, so a role would be good. However, if you keep the list box, any order would be fine (maybe alphabetic with the management network as default?). Will update page accordingly 1. c. A word of warning: sometimes a host interface's IP address is missing in the engine - this usually happens when they're configured for the first time with DHCP, and the setup networks command returns before an IP address is allocated (this can later be resolved by refreshing host capabilities, there's a button for that). So when displaying items in the list box, you should really check that an IP address exists for each network. 2. Storage Network: if you intend to keep this role in the feature (I don't think it adds a lot of functionality, see article 1b), it might be better to call it Gluster Network - otherwise people using virt mode might think this network is gonna be used to communicate with other types of storage domains. Could this network be reused for other storage needs also. If not, we can rename it gluster network I don't think there are any current plans to incorporate a storage network in 3.6, CCing Allon though. Yours, Lior. On 12/01/15 14:00, Sahina Bose wrote: Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 12/01/15 14:44, Oved Ourfali wrote: Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks. 3. Adding to 2, perhaps using DNS names is a more valid approach? 4. You're using the terminology role, but it might be confusing, as we have roles with regards to permissions. Consider changing storage usage and not storage role in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use. Thanks, Oved - Original Message - From: Sahina Bose sab...@redhat.com To: devel@ovirt.org, users us...@ovirt.org Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Bump to 3.6 default cluster version
On 01/01/15 15:49, Eli Mesika wrote: - Original Message - From: Lior Vernia lver...@redhat.com To: devel@ovirt.org Cc: Eli Mesika emes...@redhat.com Sent: Thursday, January 1, 2015 3:42:18 PM Subject: Bump to 3.6 default cluster version Hello, Could we add the 3.6 version on master and change that to the default DC/cluster version? Some features are already merged, so they could be used and bugs could be found earlier by people working on master (mostly us developers I guess) once the version is bumped. I saw 6199b29506253eeae9712afea71a3641727de71b for 3.5 - however, I'm not sure I understand the logic behind what config values need to be added for old features to work, so I'd prefer not to be the one sending the patch. I already sent a draft on that http://gerrit.ovirt.org/#/c/36518/ I need reviews from network, storage , gluster virt Ahh, thank you! Just in time :) I'll take a look for network! Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Bump to 3.6 default cluster version
Hello, Could we add the 3.6 version on master and change that to the default DC/cluster version? Some features are already merged, so they could be used and bugs could be found earlier by people working on master (mostly us developers I guess) once the version is bumped. I saw 6199b29506253eeae9712afea71a3641727de71b for 3.5 - however, I'm not sure I understand the logic behind what config values need to be added for old features to work, so I'd prefer not to be the one sending the patch. Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [UI] Start/stop progress automatically
Just an update that [1] (the important part) is merged. This means you (the frontend developer) would normally not need to trigger startProgress() and stopProgress() yourself anymore. Maintainers - feel free to remove such code at your leisure (as shown in [2]). On 09/12/14 02:57, Greg Sheremeta wrote: On 12/08/2014 09:01 AM, Lior Vernia wrote: Hello guys, I've made an attempt to solve the following bug, which deals with dialogs that don't display progress when dispatching backend actions and therefore enable users to create entities twice, etc.: https://bugzilla.redhat.com/show_bug.cgi?id=1167327 I've posted a first patch [1] that is supposed to implement generic infrastructure to handle progress display based on async events. Put relevant reviewers as I saw fit. Posted another patch [2] that shows what kind of code will be made redundant by the previous patch - I have no intention of removing all that code myself, I trust maintainers to do so at their leisure. Of course future code won't require manual progress handling at all... The first patch also *seemingly* rendered a lot of code redundant in several storage/virt flows, which is removed [3]. Put relevant people as reviewers, but would also appreciate help verifying (as I'm not familiar with many of the flows, especially storage). Yours, Lior. [1] http://gerrit.ovirt.org/#/c/35964/ [2] http://gerrit.ovirt.org/#/c/35965/ [3] http://gerrit.ovirt.org/#/c/35966/ ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel Looks great to me. Frontend is very understandable, and much cleaner. Well done. +1 to all :) Greg ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [UI] Start/stop progress automatically
Hello guys, I've made an attempt to solve the following bug, which deals with dialogs that don't display progress when dispatching backend actions and therefore enable users to create entities twice, etc.: https://bugzilla.redhat.com/show_bug.cgi?id=1167327 I've posted a first patch [1] that is supposed to implement generic infrastructure to handle progress display based on async events. Put relevant reviewers as I saw fit. Posted another patch [2] that shows what kind of code will be made redundant by the previous patch - I have no intention of removing all that code myself, I trust maintainers to do so at their leisure. Of course future code won't require manual progress handling at all... The first patch also *seemingly* rendered a lot of code redundant in several storage/virt flows, which is removed [3]. Put relevant people as reviewers, but would also appreciate help verifying (as I'm not familiar with many of the flows, especially storage). Yours, Lior. [1] http://gerrit.ovirt.org/#/c/35964/ [2] http://gerrit.ovirt.org/#/c/35965/ [3] http://gerrit.ovirt.org/#/c/35966/ ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] howto: Profiling JavaScript
Thanks Greg, was very helpful for me! Had no idea it was so simple (and specifically that Java method names would be translated so nicely to JavaScript with the right build flag). On 11/11/14 05:42, Greg Sheremeta wrote: Hopefully someone finds this helpful :) http://www.ovirt.org/Profiling_JavaScript ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Management network as a role - design proposal
On 15/08/14 12:55, Dan Kenigsberg wrote: On Thu, Aug 14, 2014 at 11:52:41AM -0400, Yevgeny Zaspitsky wrote: Hi All, The proposed feature will allow defining an arbitrary network in the DC as the management network for the cluster, which in its turn will allow assigning different VLANs for the management networks in the same DC. Feature page can be found here - http://www.ovirt.org/Features/Management_Network_As_A_Role . Please take a look into the page especially into Open issues section. I'd like to have your opinions on that. May I ask why you change the default management network from ovirtmgmt to Management? (And why the upercase M?) I think what Yevgeny meant to write was that this MIGHT be an interesting opportunity to eliminate the difference in mgmt network naming between oVirt and RHEV, which will facilitate moving between them (if users either find that they require or no longer require Red Hat support). Assuming that it's possible to make this change without affecting existing deployments, which I think it is, this sounds good to me (although not necessarily Management). Keep in mind that once the management network is just a role, the default network appearing in oVirt is potentially just that - a default network, like the default DC and cluster, aimed at making a first setup easier. It is no longer (necessarily) the management network that has to be present due to business logic constraints. Regarding your open question: Creating new cluster would have to receive the new parameter (management network) This new parameter should be kept optional, with a default value of ovirtmgmt. This way, a user that is unaware of the new feature, would see no change in functionality. I agree that this parameter should probably not be mandatory, in fact I'm not sure that it should exist at all. There are definitely other alternatives and I would expect a more thorough discussion of this and of other flows. Let's imagine a new cluster is created, and nothing happens by default. Maybe the right thing to do would just be to endow all special roles upon the first network assigned to the cluster, and allow users to change it later as they see fit? Or maybe it's okay to have a cluster without any management network, and just have all hosts added to it non-operational until users choose one? Installation should still technically succeed because a host is added by supplying an IP address or FQDN (oVirt might still say that the installation failed in this case as the management network wasn't configured - in which case maybe we should change this behavior). Successive Setup Networks operations will fail while no management network is attached to the host. The feature page should discuss the possibility of chaning the management role. Is it supported after there are hosts in the cluster? If we allow that, there's a bit of complexity. The management network's gateway is used as the default route of each host. If you change the role, all hosts should be notified (with a new setupNetwork command). I think that the cleanest solution would be to allow editing, but report the hosts as out-of-sync. This approach requires a Vdsm-side change - it would need to report which of its network is the default route. I'm not a fan of sending out batch host operations on the basis of a network cluster role change - this isn't something that is currently associated with role changes. The easiest thing would be to block the action if any hosts are active in the cluster - I'm not sure this is a bad idea, as I don't think the management network will be changed often. The second easiest thing to do would be nothing - let the hosts move to non-operational if they don't have the new management network configured, or stay active if they do, but that will still leave their default route the way it was (this added complexity is why it's only the second easiest). What is the rationale behind the coupling between management network and default routing? That it is the one network that is guaranteed to work? Maybe it would be a good idea to decouple them and allow to supply a default route for a host independently? Other flows that aren't covered: * What happens when a host is moved between clusters? * What happens when a cluster is moved between DCs? I would expect some sort of reference to these. Dan. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [GUI] Generic Event/IEventListener
Hello developers, I've just pushed a patch which renders the Event and IEventListener generic, parameterized by the type of event arguments they receive, reviews are welcome (note some preceding and succeeding patches): http://gerrit.ovirt.org/#/c/31194/ If merged, this should enable us to slowly remove unsafe casts, e.g. as is often done with PropertyChangedEventArgs. I have used this (in succeeding patches) to eliminate a couple of such coverity scan defects. It will also add a lot of IDE warnings until most events and listeners are properly parameterized, as was the case with the parameterization of EntityModel and ListModel... Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] propose Alona Kaplan as a Backend Maintainer
+1 On 29/07/14 09:46, Livnat Peer wrote: Hi All, Alona Kaplan has been working on the oVirt project for over 2.5 years. At the beginning Alona's focus was on the UI aspect of the project, she did a great Job contributing many features, bug fixes and documentation enhancements across the UI, she became a UI maintainer. In the last year Alona also contributed a lot of code to the backend side of the project, the code was focused on the network side and included end to end features. To share some of Alona's great stats - ~ 115 patches related to the network backend ~ 300 patches for UI She coded 'migration-network', 'network-linking' and lately 'support in different VLAN names' end to end. I would like to thank Alona for her great contribution and hope for many more patches to come :) I would also like to propose Alona as a Network backend maintainer. Thanks, Livnat ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [QE] [ACTION NEEDED] oVirt 3.5.0 Test Day wiki
I edited the document earlier this week, but today tried again and got the following error: You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in the group: Users. Known issue? On 23/06/14 17:23, Sandro Bonazzola wrote: Hi, as you should know we're going to have oVier 3.5 first test day on Jul 1st. Maintainers and community, please start filling test day wiki [1] with relevant tests needed. [1] http://www.ovirt.org/OVirt_3.5_TestDay ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [QE] [ACTION NEEDED] oVirt 3.5.0 Test Day wiki
On 26/06/14 14:03, Sandro Bonazzola wrote: Il 26/06/2014 13:00, Lior Vernia ha scritto: I edited the document earlier this week, but today tried again and got the following error: You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in the group: Users. Known issue? Did you logged in to the wiki today? If yes, I think this is a new issue. Logged in since yesterday. Logged out and back in now and everything worked fine, sorry for the noise :) On 23/06/14 17:23, Sandro Bonazzola wrote: Hi, as you should know we're going to have oVier 3.5 first test day on Jul 1st. Maintainers and community, please start filling test day wiki [1] with relevant tests needed. [1] http://www.ovirt.org/OVirt_3.5_TestDay ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [oVirt 3.5 Localization Question #2] Update display network on cluster with an active VM (audit log)
Thanks Yuko, it does appear that the message should have been phrased in the past tense. We will correct it. On 18/06/14 10:54, Yevgeny Zaspitsky wrote: That is the warning to the user that means that an update to the display network has been done, which means that he might expect loosing display connectivity to the VMs that were active at the time of the update action in some cases of the update. Regards, Yevgeny On 18/06/14 04:02, Yuko Katabami wrote: Hello again. I would like to ask another question with the following details: *File:***LocalizedEnums* **Resource ID:*** AuditLogType___NETWORK_UPDATE_DISPLAY_FOR_CLUSTER_WITH_ACTIVE_VM* **Strings:** * Update display network on cluster with an active VM *Question:* Is this string an instruction to the user to update the display network? Since the resource ID suggests it is audit log, there might be a possibility that it is actually meant to be a past event (i.e. Updated). Kind regards, Yuko ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] GWT/Frontent - Looking for convinient way to seperate the data from presentation in combo boxes
Hi Yair, I think this is exactly what happens in our GUI in most list boxes. The class ListModelListBoxT renders the options for display using a Renderer passed to its constructor, but getValue() returns the actual selected item of type T rather than the String (and this in turn is what is set as the selected item in the backing ListModelT). Does this answer your question? Yours, Lior. On 14/06/14 11:20, Yair Zaslavsky wrote: HI all, If you look at this link - http://www.w3schools.com/tags/tag_select.asp It shows a selection in which you have a differentiation between the displayable value, and the data value (which will be sent as the selected value). How can I do the same in GWT? At ListModel for example I saw methods only to add items. Thanks, Yair ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Sortable Ui Columns
On 02/06/14 18:22, Alexander Wels wrote: On Monday, June 02, 2014 10:46:08 AM Vojtech Szocs wrote: - Original Message - From: Vojtech Szocs vsz...@redhat.com To: aw...@redhat.com Cc: devel@ovirt.org Sent: Monday, June 2, 2014 4:37:27 PM Subject: Re: [ovirt-devel] Sortable Ui Columns - Original Message - From: Alexander Wels aw...@redhat.com To: Lior Vernia lver...@redhat.com Cc: devel@ovirt.org Sent: Monday, June 2, 2014 3:35:51 PM Subject: Re: [ovirt-devel] Sortable Ui Columns On Monday, June 02, 2014 11:27:26 AM Lior Vernia wrote: After discussing this with Alex on another thread, I just pushed this: http://gerrit.ovirt.org/#/c/28268/ If it's approved, then it'll take care of the secondary criterion for you, so you only need to pass the criterion that actually interests you. Should simplify our work in the next couple of weeks. Okay, I think we need to get everyone on the same page with this, right now we have several solutions to the problem, and I think we should pick one and go with that. Right now we have the following solutions available: 1. Attempt to keep the current order in case of 'duplication' in the comparator. So the fallback is to keep the current order. This is implemented in Liors patch [1]. 2. Use the hash code as a fallback in case of 'duplication' in the comparator. Due to hashcode rules this should result in the 'natural' order in case of duplicates. This is implemented in my patch [2]. 3. Do ad-hoc fallback mechanism which can specialize to do the proper thing based on domain knowledge. It looks like this is what Anmol is doing in his gluster sorting patch [3] 4. Replace the SortedSet with a List but lose the ability to automatically sort when calling getItems().add(X). To me it seems that 3 and 4 are off the table as we want to keep the ability to automatically sort. And doing ad hoc solutions for every single sorting column is going to take a lot of time and is going to lead to maintainability issues down the road. That leaves 1 and 2 on which I would like to have a discussion, so we can pick the appropriate method and go forward with that. I just reviewed Lior's patch and posted some comments: http://gerrit.ovirt.org/#/c/28268/2/frontend/webadmin/modules/uicommonwe b/src/main/java/org/ovirt/engine/ui/uicommonweb/models/SortedListModel.j ava Initially, I thought that computing item positions based on the order in which they are returned by Collection's iterator might be unreliable, now that I think more about it, I think this approach is something we should consider. In other words, in edge case when comparing two items with same logical property (i.e. two Data Centers with same name), we should honor the ordering of items within the original Collection provided by the server. Otherwise, comparing hashCode might change their order in such edge case. So actually it seems better to preserve Collection's iteration order rather than preserving natural order in such edge case. Just wanted to mention one more idea I just realized while talking with Alex: after we move to REST API, there won't be any hashCode anymore. We'll receive a collection (array) of items (objects) with IDs, which means hashCode will become backend business entity impl. detail. This is also the reason why I'm more inclined towards preserving order of items within original collection; there won't be any natural ordering of items after we move to REST API. Thinking about Liors patch a little bit doesn't it have the same problem as just replacing the sorted set with a list that we sort? doing getItems().add(item) will cause the sorting to no longer work, as that new item won't be in the positions map. So essentially this doesn't work any better than replacing the SortedSet with some sort of List. You are correct that it needs to be tweaked a little to accommodate that, but it can. I'll push a new patchset and let's discuss this on the patch itself. What do you think guys? [1] http://gerrit.ovirt.org/#/c/28268/ [2] http://gerrit.ovirt.org/#/c/28225/ [3] http://gerrit.ovirt.org/#/c/28233/ On 31/05/14 15:35, Anmol Babu wrote: Thanks a lot Alexander.Your idea of having a second criteria based sorting just in case of comparing same values(compare returning 0) looks good to me and now, I have also done the same in my patch set http://gerrit.ovirt.org/#/c/28233/.I have added you as a reviewer as well. Thanks, Anmol - Original Message - From: Alexander Wels aw...@redhat.com To: devel@ovirt.org Cc: Anmol Babu anb...@redhat.com Sent: Friday, May 30, 2014 5:55:20 PM Subject: Re: [ovirt-devel] Sortable Ui Columns Anmol, This is due to the fact that the sorting is done by a SortedSet instead of a list in the SortedListModel. To fix this we have to do one of two things: 1. Change the sorting to use a list of some sort, but apparently that is not much
Re: [ovirt-devel] SortedListModel
On 29/05/14 18:44, Alexander Wels wrote: On Thursday, May 29, 2014 04:29:11 PM Lior Vernia wrote: Hello Alex, On 29/05/14 16:05, Alexander Wels wrote: Hi guys, I have a question about the SortedListModel. If you look at the setItems(CollectionT value) method. You will notice that eventually all the items are added to a SortedSet. This is not a problem if all the elements of your collection are different. But what happens if the elements of your collection are not all different. More specifically if I pass in a comparator that matches on a field of the object that is not different like description, or size or something of that nature. The set will reduce the number of elements. Before I change it to be a list that can have duplicates, I would like to know the origin of the set and if there are going to be any issues when I do that. It was originally conceived as a way to consistently keep items in a sorted manner, whether they're added via setItems() or getItems().add(). It had nothing to do with the fact that duplicates aren't allowed, so I doubt a change will adversely affect current uses (of which there aren't many, if I'm not mistaken, so it's better to verify). However, a list doesn't automatically sort itself as items are added, so you should preserve that functionality if you decide to change the implementation. You could implement a customized List that invokes sort() upon add(). I think the current implementation is far more efficient in that insertion and removal is done in O(logn), whereas the alternative would be O(n). You might say that's not important, I think it might be important for scalability in the future. Personally I think that having correct behavior is more important than having incorrect but fast behavior. Basically the set works fine if you use the natural order of the objects. However if you pass in a different Comparator the set falls apart as you now potentially have duplicates based on the Comparator. A good example is entities with a description or comment field. If I pass in a Comparator that simply compares the description field of the entities, I can and do have duplicates. The resulting collection is now smaller than the original which is obviously not what we want. First of all, I'm not sure that description and comment are useful columns to sort by. Secondly, I saw you mentioned in another thread that you were using a compound comparator with a secondary property to sort by - I think this is a very correct solution, and actually something we should do regardless of the issue you raised; otherwise on refresh items could switch places. So I would try to have comparators enforce a consistent ordering (i.e. never return 0). By the way, a good secondary sort property would be the item's position in the collection prior to sorting. This would enable users to implicitly define secondary (and tertiary, etc.) sort criteria, according to the order in which they clicked on column headers. And of course it satisfies consistency. When I get to the network-related sorting (next couple of days) I'll see if I can design a nice shareable utility to help with that and put it in the Linq class. You are right that I will be unable to force a sort when someone does a getItems.add. There seems to be only one data structure in java that is automatically sorted on adds as well as allows for duplicate entries, which is a PriorityQueue. Since we are using Collections this should not be a problem, however if anyone casts it to a list, it will explode. ...or SortedSet, which is why it was used :) And which would also explode if cast to List. Which is okay because ListModel only guarantees a Collection to be returned - casting to List isn't great practice. There is the other choice of using a customized List in ListModel, which would work perfectly fine. But if comparators are constructed so that they never return 0, as discussed above, this becomes a non-issue. But frankly, it's not difficult to notice what one inserts into their SortedListModel, and to make sure that its equals() method is consistent with what they're trying to achieve (or wrap the items in case it isn't). Thanks, Alexander ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] how to call the SW part of instance type?
On 30/05/14 15:17, Tomas Jelinek wrote: Hey all, in the instance type feature [1] there are two parts, the instance types (HW part of the machine) and the something not sure how to call (which is basically a disk image with some SW related metadata like OS type). It is inspired by the Amazon's Instance Type + AMI. Since it's similar to the existing concept of image maybe the two can be merged; e.g. the existing one could be extended, or another type of image could be added (I think there are quite a few already). If not, then how about Payload? VM Payload? I'm thinking of instance type as a container, and this would be what goes inside the container. Currently, the handling of the HW part is merged upstream (some small parts missing but mostly there) but the software part is not. I'd like to start implementing it and wanted to ask the community how to call it. Normally it would be called image, but since we already have images in oVirt it would be confusing. I see this options how to call it, please feel free to comment on them, vote for some or propose a new name (please keep in mind that the HW part is called Instance Type). - Instance Image - Software Profile - OMI (oVirt Machine Image) - System Image - ITI (Instance Type Image) Thank you, Tomas [1]: http://www.ovirt.org/Features/Instance_Types ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] fixing whitespace in ui.xml files
Sounds good to me, I think the only reason they're not formatted is that the Java formatter by default ignores them. On 29/05/14 14:51, Greg Sheremeta wrote: Hi, Can we agree to use the same .java file space standards in our gwt ui.xml files? Specifically: spaces only, no tabs, 4 spaces indent, no trailing whitespace. I have my Eclipse set to fix these things (with the anyedit plugin), and the ui.xml files always have tabs and trailing space in them. If we agree, I volunteer to fix them all and post a patch. I think we can also set gerrit to point these out. Thanks, Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gsher...@redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 16:02, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org
Sent: Monday, May 5, 2014 7:08:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
Hey guys (and gals),
A few patches are up for review starting at:
http://gerrit.ovirt.org/#/c/27383
In total, about 250 lines of code removed, hopefully not at the cost of
regression. I put down some reviewers as I saw fit, but everyone can
feel free to add themselves. Summary of what was done compared to the
original plan:
1. Removed said dependencies, except for DeviceCustomPropertiesUtils
that was using the capture groups features of Pattern, and thus remained
in the utils project.
2. Done.
3. Done.
4. Almost didn't touch this, it seems to involve a lot of moving parts.
Yours, Lior.
On 30/04/14 18:01, Vojtech Szocs wrote:
Hi Lior, please find my comments inline.
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Lior Vernia lver...@redhat.com
Cc: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:28:06 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
- Original Message -
From: Lior Vernia lver...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:52:16 PM
Subject: [ovirt-devel] Custom Properties code duplication
Hello,
While adding network custom properties towards oVirt 3.5, I got to take
a good look at the custom properties code in the backend and frontend.
It seems to me like there's a lot of code duplication, and I would like
to suggest the following refactoring:
1. Remove dependencies on Pattern/Matcher and ApacheCommons methods from
*CustomPropertiesUtils.java, to make them compilable with GWT, and move
these utilities to the common package. The usage of the said methods is
minimal and could easily be replaced with String methods, etc.
+1
In general I am in favor, but how are you going to perform the regex
validation of values?
for example , with vm custom properties, you have - sap_agent that can be
either true or false.
So you need to validate both at the client and the engine, right?
Lior mentioned above the possibility of using String methods, I assume
by this he means java.lang.String.matches(String) and similar methods.
During GWT compilation, JRE standard String implementation is replaced
by emulated (GWT-friendly) String implementation, which implements
methods like matches(String) using JavaScript RegExp object. You can
find this emulated implementation here:
gwt-user-{version}-sources.jar/com/google/gwt/emul/java/lang/String.java
Another alternative is to use GWT's built-in regex support through
com.google.gwt.regexp.shared.RegExp class. GWT's RegExp class has two
implementations, default one using JRE Pattern/Matcher, emulated one
using JavaScript RegExp object. The advantage is (mostly) consistent
regex support on both client and server, the disadvantage is server's
dependency on GWT JAR. (I don't think we want this.)
For simple regex matches, I'd suggest to simply go with String approach.
For complex regex matches, we can use JRE Pattern/Matcher on server,
and emulate given implementation using GWT RegExp on client.
Note that there are (slight) differences between JRE's Pattern/Matcher
and JavaScript's RegExp object syntax/behavior. Check GWT RegExp class
Javadoc to see details (for simple cases, it's not a big deal, though).
2. Modify KeyValueModel to delegate to the common utilities instead of
duplicating code, e.g. for validation.
+1
I see that KeyValueModel uses RegexValidation class that delegates to
compat's Regex class. Just like above, default Regex class utilizes
JRE Pattern/Matcher but client uses emuluated implementation:
gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Regex.java
and this emulated implementation uses GWT RegExp class.
3. Move some validation, which is relevant to all custom properties
(e.g. duplicate keys), from specific utils (e.g. VmPropertiesUtils) up
to the shared CustomPropertiesUtils.
+1
4. Optionally change the implementation of custom properties members in
entities (e.g. VM) from String to MapString, String, which would
obviate the need for different conversion methods between String/Map -
(de)serialization would only be required in DB interaction.
+1
3,4 Agreed - good points.
The main argument against this would be that the frontend is to be moved
over the REST, and might not be written in Java much longer anyway.
:) I think there's a misunderstanding regarding our move to REST API.
I think there isn't any misunderstanding here. I think that common code is
not the best practice here, as Lior mentioned briefly.
IMO one of the main reasons of using the REST is repo/project separation,
some points to consider:
1) who will maintain the common
Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 18:57, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 5:32:38 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 16:02, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org
Sent: Monday, May 5, 2014 7:08:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
Hey guys (and gals),
A few patches are up for review starting at:
http://gerrit.ovirt.org/#/c/27383
In total, about 250 lines of code removed, hopefully not at the cost of
regression. I put down some reviewers as I saw fit, but everyone can
feel free to add themselves. Summary of what was done compared to the
original plan:
1. Removed said dependencies, except for DeviceCustomPropertiesUtils
that was using the capture groups features of Pattern, and thus remained
in the utils project.
2. Done.
3. Done.
4. Almost didn't touch this, it seems to involve a lot of moving parts.
Yours, Lior.
On 30/04/14 18:01, Vojtech Szocs wrote:
Hi Lior, please find my comments inline.
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Lior Vernia lver...@redhat.com
Cc: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:28:06 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
- Original Message -
From: Lior Vernia lver...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:52:16 PM
Subject: [ovirt-devel] Custom Properties code duplication
Hello,
While adding network custom properties towards oVirt 3.5, I got to take
a good look at the custom properties code in the backend and frontend.
It seems to me like there's a lot of code duplication, and I would like
to suggest the following refactoring:
1. Remove dependencies on Pattern/Matcher and ApacheCommons methods
from
*CustomPropertiesUtils.java, to make them compilable with GWT, and move
these utilities to the common package. The usage of the said methods is
minimal and could easily be replaced with String methods, etc.
+1
In general I am in favor, but how are you going to perform the regex
validation of values?
for example , with vm custom properties, you have - sap_agent that can
be
either true or false.
So you need to validate both at the client and the engine, right?
Lior mentioned above the possibility of using String methods, I assume
by this he means java.lang.String.matches(String) and similar methods.
During GWT compilation, JRE standard String implementation is replaced
by emulated (GWT-friendly) String implementation, which implements
methods like matches(String) using JavaScript RegExp object. You can
find this emulated implementation here:
gwt-user-{version}-sources.jar/com/google/gwt/emul/java/lang/String.java
Another alternative is to use GWT's built-in regex support through
com.google.gwt.regexp.shared.RegExp class. GWT's RegExp class has two
implementations, default one using JRE Pattern/Matcher, emulated one
using JavaScript RegExp object. The advantage is (mostly) consistent
regex support on both client and server, the disadvantage is server's
dependency on GWT JAR. (I don't think we want this.)
For simple regex matches, I'd suggest to simply go with String approach.
For complex regex matches, we can use JRE Pattern/Matcher on server,
and emulate given implementation using GWT RegExp on client.
Note that there are (slight) differences between JRE's Pattern/Matcher
and JavaScript's RegExp object syntax/behavior. Check GWT RegExp class
Javadoc to see details (for simple cases, it's not a big deal, though).
2. Modify KeyValueModel to delegate to the common utilities instead of
duplicating code, e.g. for validation.
+1
I see that KeyValueModel uses RegexValidation class that delegates to
compat's Regex class. Just like above, default Regex class utilizes
JRE Pattern/Matcher but client uses emuluated implementation:
gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Regex.java
and this emulated implementation uses GWT RegExp class.
3. Move some validation, which is relevant to all custom properties
(e.g. duplicate keys), from specific utils (e.g. VmPropertiesUtils) up
to the shared CustomPropertiesUtils.
+1
4. Optionally change the implementation of custom properties members in
entities (e.g. VM) from String to MapString, String, which would
obviate the need for different conversion methods between String/Map -
(de)serialization would only be required in DB interaction.
+1
3,4 Agreed - good points.
The main argument against this would be that the frontend is to be
moved
over the REST, and might not be written in Java much longer anyway.
:) I think there's
Re: [Engine-devel] GUI widget for adding/removing entries
Last patches were recently merged to the master branch; many thanks to Tomas, Vojtech and Gilad for taking the time to review them (weren't easy to review). The following widgets now all use the same underlying widget: * VM interfaces in add/edit VM dialog. * Profiles in add/edit network dialog. * Device custom properties in add/edit vNIC profile dialog. * Custom properties in add/edit VM dialog. * Custom properties in add/edit cluster dialog. * Custom properties in add/edit cluster policy dialog. * Custom properties in VM run once dialog. I did my best to avoid regressions, but please let me know if any of these seem to malfunction all of a sudden. Yours, Lior. On 10/10/13 16:01, Einav Cohen wrote: see attached: AFAIK, there are three types of adding-and-removing widget in the application: (1) the one that exists in the customs properties section as well as the cluster policy. in this widget: - the + and - buttons appear on every row. - row is identified by a selected item from a drop down. - input controls in row: drop-down and text box (that appears upon selection of a non-empty value in the drop-down) (2) the one that exists in the vNICs assignment part of the General section in the New VM dialog. in this widget: - the + appears only in the last row, - appears in all lines but the last row. - row is identified by (what seems to be a) read-only label (I assume that this widget is built to be initially loaded to already contain a number of rows, as opposed to (1), which typically starts with no rows / initial empty row. - input controls in row: drop-down (3) the one that exists in the vNIC profiles section in the Add/Edit Network dialog in this widget: - the + and - buttons appear on every row. - row is identified by a free-text string. - input controls in row: text-box, check-box and drop-down. so there are differences between the widgets other than the + and - buttons. however, from ux perspective, it is important to keep the look-and-feel of all of them consistent. technically (code-wise), I am not sure how easy it is to merge the three, due to the differences. we can maybe think of creating a general adding-and-removing-entries widget, which can support ordered and non-ordered flavors (which will affect the +/- buttons appearance / exact behavior), and it will contain a collection of abstract row-widgets (and we will have several implementations of row-widgets for each needed functionality [(1), (2), (3)] with exact appearance / input controls / behavior/etc.), which may need to support a certain api (e.g. isRowEmpty(), get/set Identifier(), etc.) in order to communicate appropriately with its parent adding-and-removing-entries widget. thoughts? - Original Message - From: Lior Vernia lver...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, October 10, 2013 4:44:47 AM Subject: Re: [Engine-devel] GUI widget for adding/removing entries To my knowledge, such a widget existed only in two other places: custom properties and vNIC profiles in add/edit network dialog. In both of them the order wasn't important, in which case the new widget is probably preferable. If it is indeed preferable (Einav? Malini?), I could do some refactoring to have both of them use it. On 10/10/13 09:02, Itamar Heim wrote: On 10/10/2013 10:59 AM, Lior Vernia wrote: On 09/10/13 23:34, Itamar Heim wrote: On 10/09/2013 03:32 PM, Lior Vernia wrote: Of course, my bad. Attached is a screenshot of the add/edit VM dialog, note the vNIC part on the bottom half of the dialog. how is it different from the custom properties one? Design-wise, there are a couple of small differences. There's only one button next to each row, plus if it's the last row or minus otherwise (so items can only be added at the end, as I replied to Malini order hasn't been important so far). A row appears as disabled until it is edited, and a disabled row is ignored when the view is flushed back to the model (e.g. when the user presses OK in the dialog). Code-wise, it's constructed to be reusable, which the custom properties widget wasn't :) could we converge on one of them though? On 09/10/13 13:24, Einav Cohen wrote: Hi Lior - can you please provide a screen-shot, so we will know which widget you are referring to? will make it easier for people to decide if and where to use this widget. Many thanks! Regards, Einav - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, October 9, 2013 4:34:29 AM Subject: [Engine-devel] GUI widget for adding/removing entries Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so
Re: [Engine-devel] [UX] how to design a bar/line chart?
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 ih...@redhat.com To: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Tuesday, November 5, 2013 10:10:34 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? On 11/05/2013 11:50 AM, Tomas Jelinek wrote: Hi all, There is a feature request [1] which aims to replace the resource utilization graphs (for example the cpu utilization from vm tab) by some which shows not only the actual percentage which is not so useful by some monitor graph. I have the following concerns: - I can think of a bar chart or a line chart and not sure what would be better. - Not sure if replacing the current chart with a bar/line chart would make the statistics readable enough. Maybe if you hover the chart it could pop up a bigger version of the chart? Or not needed? - Would it be enough to have it in one color? Or should it be something like the bigger the utilization the more red? Please advise from the UX perspective. As soon as the final design will be a bit more clear I will provide a feature page. Thank you, Tomas [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel a moving trend graph (just like fedora's system monitor for cpu/ram/network) is what i have in mind. so a line chart. you could have a single chart with different lines for cpu/ram/network, or what seems to be more common, a chart per monitored fact ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [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. - Original Message - From: Itamar Heim ih...@redhat.com To: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Tuesday, November 5, 2013 10:10:34 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? On 11/05/2013 11:50 AM, Tomas Jelinek wrote: Hi all, There is a feature request [1] which aims to replace the resource utilization graphs (for example the cpu utilization from vm tab) by some which shows not only the actual percentage which is not so useful by some monitor graph. I have the following concerns: - I can think of a bar chart or a line chart and not sure what would be better. - Not sure if replacing the current chart with a bar/line chart would make the statistics readable enough. Maybe if you hover the chart it could pop up a bigger version of the chart? Or not needed? - Would it be enough to have it in one color? Or should it be something like the bigger the utilization the more red? Please advise from the UX perspective. As soon as the final design will be a bit more clear I will provide a feature page. Thank you, Tomas [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel a moving trend graph (just like fedora's system monitor for cpu/ram/network) is what i have in mind. so a line chart. you could have a single chart with different lines for cpu/ram/network, or what seems to be more common, a chart per monitored fact ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] GUI widget for adding/removing entries
On 10/10/13 16:01, Einav Cohen wrote: see attached: AFAIK, there are three types of adding-and-removing widget in the application: (1) the one that exists in the customs properties section as well as the cluster policy. in this widget: - the + and - buttons appear on every row. - row is identified by a selected item from a drop down. - input controls in row: drop-down and text box (that appears upon selection of a non-empty value in the drop-down) (2) the one that exists in the vNICs assignment part of the General section in the New VM dialog. in this widget: - the + appears only in the last row, - appears in all lines but the last row. - row is identified by (what seems to be a) read-only label (I assume that this widget is built to be initially loaded to already contain a number of rows, as opposed to (1), which typically starts with no rows / initial empty row. - input controls in row: drop-down (3) the one that exists in the vNIC profiles section in the Add/Edit Network dialog in this widget: - the + and - buttons appear on every row. - row is identified by a free-text string. - input controls in row: text-box, check-box and drop-down. so there are differences between the widgets other than the + and - buttons. however, from ux perspective, it is important to keep the look-and-feel of all of them consistent. technically (code-wise), I am not sure how easy it is to merge the three, due to the differences. we can maybe think of creating a general adding-and-removing-entries widget, which can support ordered and non-ordered flavors (which will affect the +/- buttons appearance / exact behavior), and it will contain a collection of abstract row-widgets (and we will have several implementations of row-widgets for each needed functionality [(1), (2), (3)] with exact appearance / input controls / behavior/etc.), which may need to support a certain api (e.g. isRowEmpty(), get/set Identifier(), etc.) in order to communicate appropriately with its parent adding-and-removing-entries widget. thoughts? What you described is pretty much how the abstract AddRemoveRowWidget works, so it should be fairly easy to merge the three (it was designed to be so). The widget doesn't care about the exact nature of the content widget to the left of the plus/minus button, that information is given when overriding the aforementioned abstract methods. The only difference is that there's only one flavor at the moment, which is orderless, since none of these current examples is mindful of ordering. - Original Message - From: Lior Vernia lver...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, October 10, 2013 4:44:47 AM Subject: Re: [Engine-devel] GUI widget for adding/removing entries To my knowledge, such a widget existed only in two other places: custom properties and vNIC profiles in add/edit network dialog. In both of them the order wasn't important, in which case the new widget is probably preferable. If it is indeed preferable (Einav? Malini?), I could do some refactoring to have both of them use it. On 10/10/13 09:02, Itamar Heim wrote: On 10/10/2013 10:59 AM, Lior Vernia wrote: On 09/10/13 23:34, Itamar Heim wrote: On 10/09/2013 03:32 PM, Lior Vernia wrote: Of course, my bad. Attached is a screenshot of the add/edit VM dialog, note the vNIC part on the bottom half of the dialog. how is it different from the custom properties one? Design-wise, there are a couple of small differences. There's only one button next to each row, plus if it's the last row or minus otherwise (so items can only be added at the end, as I replied to Malini order hasn't been important so far). A row appears as disabled until it is edited, and a disabled row is ignored when the view is flushed back to the model (e.g. when the user presses OK in the dialog). Code-wise, it's constructed to be reusable, which the custom properties widget wasn't :) could we converge on one of them though? On 09/10/13 13:24, Einav Cohen wrote: Hi Lior - can you please provide a screen-shot, so we will know which widget you are referring to? will make it easier for people to decide if and where to use this widget. Many thanks! Regards, Einav - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, October 9, 2013 4:34:29 AM Subject: [Engine-devel] GUI widget for adding/removing entries Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so the idea is to make adding one easy rather than copying pasting code. AddRemoveRowWidget takes care of the plus/minus button logic, disabling an entry that hasn't been edited
Re: [Engine-devel] GUI widget for adding/removing entries
Hi Malini, What do you mean by listed along with the details? Did you have something in mind? Maybe tooltips over disabled buttons to explain why they're disabled? Concerning sequence, you're correct of course. However, as far as I'm aware, so far in none of the use cases of this type of widgets was the order important, so that was my postulate when designing this widget. A similar widget could be implemented in case the ordering were important. Lior. On 09/10/13 17:36, Malini Rao wrote: I think a few interaction details listed along with the widget will be useful for anyone considering the use of this widget. For example, if the user cannot delete the last field remaining, then the minus will be disabled. Also, if the use case needs the user to be able to insert in any place in the list ( assuming that sequence is important), then building on the current model, the plus button will show on all rows etc. Thanks Malini - Original Message - From: Lior Vernia lver...@redhat.com To: Einav Cohen eco...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, October 9, 2013 8:32:09 AM Subject: Re: [Engine-devel] GUI widget for adding/removing entries Of course, my bad. Attached is a screenshot of the add/edit VM dialog, note the vNIC part on the bottom half of the dialog. On 09/10/13 13:24, Einav Cohen wrote: Hi Lior - can you please provide a screen-shot, so we will know which widget you are referring to? will make it easier for people to decide if and where to use this widget. Many thanks! Regards, Einav - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, October 9, 2013 4:34:29 AM Subject: [Engine-devel] GUI widget for adding/removing entries Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so the idea is to make adding one easy rather than copying pasting code. AddRemoveRowWidget takes care of the plus/minus button logic, disabling an entry that hasn't been edited, and the arranging in rows. In order to use it, one is required to override a couple of abstract methods that are dependent upon the specific entry implementation. An example may be found in ProfilesInstanceTypeEditor, which handles adding/removing network interfaces in the new/edit VM dialog. Yours, Lior. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] GUI widget for adding/removing entries
On 09/10/13 23:34, Itamar Heim wrote: On 10/09/2013 03:32 PM, Lior Vernia wrote: Of course, my bad. Attached is a screenshot of the add/edit VM dialog, note the vNIC part on the bottom half of the dialog. how is it different from the custom properties one? Design-wise, there are a couple of small differences. There's only one button next to each row, plus if it's the last row or minus otherwise (so items can only be added at the end, as I replied to Malini order hasn't been important so far). A row appears as disabled until it is edited, and a disabled row is ignored when the view is flushed back to the model (e.g. when the user presses OK in the dialog). Code-wise, it's constructed to be reusable, which the custom properties widget wasn't :) On 09/10/13 13:24, Einav Cohen wrote: Hi Lior - can you please provide a screen-shot, so we will know which widget you are referring to? will make it easier for people to decide if and where to use this widget. Many thanks! Regards, Einav - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, October 9, 2013 4:34:29 AM Subject: [Engine-devel] GUI widget for adding/removing entries Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so the idea is to make adding one easy rather than copying pasting code. AddRemoveRowWidget takes care of the plus/minus button logic, disabling an entry that hasn't been edited, and the arranging in rows. In order to use it, one is required to override a couple of abstract methods that are dependent upon the specific entry implementation. An example may be found in ProfilesInstanceTypeEditor, which handles adding/removing network interfaces in the new/edit VM dialog. Yours, Lior. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] GUI widget for adding/removing entries
To my knowledge, such a widget existed only in two other places: custom properties and vNIC profiles in add/edit network dialog. In both of them the order wasn't important, in which case the new widget is probably preferable. If it is indeed preferable (Einav? Malini?), I could do some refactoring to have both of them use it. On 10/10/13 09:02, Itamar Heim wrote: On 10/10/2013 10:59 AM, Lior Vernia wrote: On 09/10/13 23:34, Itamar Heim wrote: On 10/09/2013 03:32 PM, Lior Vernia wrote: Of course, my bad. Attached is a screenshot of the add/edit VM dialog, note the vNIC part on the bottom half of the dialog. how is it different from the custom properties one? Design-wise, there are a couple of small differences. There's only one button next to each row, plus if it's the last row or minus otherwise (so items can only be added at the end, as I replied to Malini order hasn't been important so far). A row appears as disabled until it is edited, and a disabled row is ignored when the view is flushed back to the model (e.g. when the user presses OK in the dialog). Code-wise, it's constructed to be reusable, which the custom properties widget wasn't :) could we converge on one of them though? On 09/10/13 13:24, Einav Cohen wrote: Hi Lior - can you please provide a screen-shot, so we will know which widget you are referring to? will make it easier for people to decide if and where to use this widget. Many thanks! Regards, Einav - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, October 9, 2013 4:34:29 AM Subject: [Engine-devel] GUI widget for adding/removing entries Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so the idea is to make adding one easy rather than copying pasting code. AddRemoveRowWidget takes care of the plus/minus button logic, disabling an entry that hasn't been edited, and the arranging in rows. In order to use it, one is required to override a couple of abstract methods that are dependent upon the specific entry implementation. An example may be found in ProfilesInstanceTypeEditor, which handles adding/removing network interfaces in the new/edit VM dialog. Yours, Lior. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] GUI widget for adding/removing entries
Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so the idea is to make adding one easy rather than copying pasting code. AddRemoveRowWidget takes care of the plus/minus button logic, disabling an entry that hasn't been edited, and the arranging in rows. In order to use it, one is required to override a couple of abstract methods that are dependent upon the specific entry implementation. An example may be found in ProfilesInstanceTypeEditor, which handles adding/removing network interfaces in the new/edit VM dialog. Yours, Lior. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] GUI widget for adding/removing entries
Of course, my bad. Attached is a screenshot of the add/edit VM dialog, note the vNIC part on the bottom half of the dialog. On 09/10/13 13:24, Einav Cohen wrote: Hi Lior - can you please provide a screen-shot, so we will know which widget you are referring to? will make it easier for people to decide if and where to use this widget. Many thanks! Regards, Einav - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, October 9, 2013 4:34:29 AM Subject: [Engine-devel] GUI widget for adding/removing entries Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so the idea is to make adding one easy rather than copying pasting code. AddRemoveRowWidget takes care of the plus/minus button logic, disabling an entry that hasn't been edited, and the arranging in rows. In order to use it, one is required to override a couple of abstract methods that are dependent upon the specific entry implementation. An example may be found in ProfilesInstanceTypeEditor, which handles adding/removing network interfaces in the new/edit VM dialog. Yours, Lior. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel attachment: AddRemoveRowWidget.png___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Lior Vernia as ovirt-UI maintainer
Thanks to everyone who backed me up, please feel free to put me down as a reviewer for your patches as I have done to you. On 03/10/13 13:26, Itamar Heim wrote: On 10/03/2013 07:16 AM, Kanagaraj wrote: +1 Thanks, Kanagaraj On 10/02/2013 03:57 PM, Livnat Peer wrote: I'd like to propose Lior Vernia as a ovirt-UI maintainer. Lior Vernia has been working on the UI for over a year, with a lot of dedication enthusiasm and motivation. He has more than 140 UI patches merged and hopefully many more in the pipeline :) Thanks, Livnat ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel seeing enough +1's, added to gerrit group ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Dynamic resource loading in GWT
Disclaimer: I don't understand the inner workings of GWT, its interplay with the browser and so forth. Some comments are interleaved below. On 07/08/13 15:23, Alexander Wels wrote: On Wednesday, August 07, 2013 02:48:45 PM Roy Golan wrote: On 08/07/2013 02:08 PM, Einav Cohen wrote: Hi Roy, a couple of notes (I could be totally wrong here, GWT experts - please review/comment): - from [1]: Provides dynamic string lookup of key/value string pairs defined in a module's host HTML page - there is a chance that a gwt dictionary is limited to reading key/value string pairs that reside within the *gwt module host HTML page* (i.e., within the context of the GWT application - http://[server]/webadmin/webadmin/...;) and not outside - need to find that out. well the file servlet resides on [server] so I don't think there a same origin policy problem here - correct me if I'm wrong (isn't branding doing something similar?) Branding is doing exactly what you are suggesting, generating a dictionary in the host page, and having the GWT application read it at runtime. The only reason we did it like that, is that there is no other way of changing some of the messages at runtime. If there was some way of doing it at compile time I would have done that. Also the number of resources changed by branding is very limited and therefore won't impact the performance as much as doing every single resource. I have no idea how difficult it would be to implement a sample case. If it's not too difficult, why not give it a shot and see if there's actually an appreciable performance hit? There are advantages and disadvantages of both methods that need to be carefully weighed, and the GWT developers themselves did that and came to the conclusion that compile time inclusion is the best method for most resources. They did however anticipate the need for some runtime resources so they included Dictionary etc. - again, from [1]: a variety of error conditions (particularly those involving key mismatches) cannot be caught until runtime. Similarly, the GWT compiler is unable discard unused dictionary values since the structure cannot be statically analyzed. (this is expected, as the suggested loading here is dynamic, rather than static) - not sure exactly how this would work with localization; there is A Caveat Regarding Locale mentioned in [1] - IIUC, we will lose the automatic locale-mapping that we have today, and we would need to do it ourselves somehow (not a big deal, I suppose, just some extra work that needs to be done here). The branding allows one to define java property bundles for all the supported languages, and will load them at runtime and put the translated strings in the Dictionary in the host page. Again I wouldn't recommend doing it for a large number of resources. indeed but it will pay off. a change off resources means ctrl+F5 and not GWT compilation :P Sure for the developer it would be great, less compiling. However for the user not so much, and in the end we are creating the software for the user and the needs of the developer are secondary to that. When I say it is not so great for the user, I mean the fact that it becomes a lot harder to cache the host page (as the contents can change), vs caching the compiled resources is really easy as the contents won't chance. It's not just about the needs of the developer - the way the error messages are distributed between different files is prone to errors, and things that are prone to errors eventually will hurt the user. Thanks, Einav [1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dicti onary.html - Original Message - From: Roy Golan rgo...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, August 7, 2013 2:59:07 AM Subject: [Engine-devel] Dynamic resource loading in GWT Painful issue here - we all know the regular drill of maintaining messages in many places, I18N files and so on. Also there's a patch to make all available timezone an java enum and by that share it for free with the UI. its a way better than a backend Query. But this is all hard-coded, not flexible, hard to maintain, we all know. Why won't we make GWT load a javascript dictionary/dictionaries from a servlet or our host page html[1] using GWT Dictionary[3]? that way the configuration is shared with the engine, it relies on the disk, customers and GSS can change it on-site and so on. | index.html | - | file servlet | - |read /etc/ovirt-engine/conf/...| | ^ | | GWT loads Dictionary | candidates for dynamic resources * I18N resources AppErrors... * config ( just the UI subset ) * osinfo ? [1] host page html - http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html#DevG uideHostPage [2] Dynamic string internationalisation - http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicStr
Re: [Engine-devel] cannot login after re-deploying development environment
Hi Einav, Happens to me repeatedly. I reset options AdminPassword and LocalAdminPassword manually in the vdc_options in the DB. Never tried the aforementioned -s AdminPassword=interactive switch for engine-setup. Lior. On 06/08/13 20:31, Einav Cohen wrote: Hi, The following scenario already happened to me several times: I created a brand new 'engine' data-base, created / deployed development environment [everything works correctly]. After ^^^, I re-create/deploy development environment, this time without creating a brand new 'engine' data-base (i.e. I utilized the existing one). Everything seems to be working correctly, only I cannot login into the web-admin (I fail on USER_FAILED_TO_AUTHENTICATE CanDoAction). The only workaround I found is to use a brand-new data-base. Any ideas? [attached: engine.log, engine-setup output, engine-setup.log] Thanks in advance. Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [oVirt 3.3 Localization Question #9] Allow All
Hello Yuko, Yes, it is allowing all users to use this network. It's supposed to be a short version of networkPublicUseLabel in the same file. Yours, Lior. On 05/08/13 11:29, Yuko Katabami wrote: Hello again. Sorry for increasing email traffic - this is my last question for today. * File: *ApplicationConstants *Resource ID: *publicNetwork *String:* Allow All *Question: *Could anyone explain the usage of this string? Is it allowing all (everyone) to use? Thank you, Yuko -- Regards, Yuko Katabami (方波見裕子) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 *Mobile:* +61 415 847 352 *Email:* ykata...@redhat.com Red Hat *Red Hat, Asia-Pacific Pty Ltd* Level 1, 193 North Quay Brisbane 4000 *Office:* +61 7 3514 8100 *Fax:* +61 7 3514 8199 *Website:* www.redhat.com http://www.redhat.com *Facebook:* Red Hat APAC http://www.facebook.com/redhatapac | Red Hat Japan http://www.facebook.com/redhatjapan | Red Hat Korea http://www.facebook.com/redhatkorea | JBoss APAC http://www.facebook.com/JBossAPAC *Twitter:* Red Hat APAC http://www.twitter.com/red_hat_apac | Red Hat ANZ http://www.twitter.com/redhatanz *LinkedIn:* Red Hat APAC http://www.linkedin.com/groups?gid=3124596 | JBoss APAC http://www.linkedin.com/groups?gid=4068303 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Sorting in tabs
Hello everyone (UI peeps in particular), I've pushed (not yet merged) a patch that would enable us to keep items in tabs (main/sub) sorted at all times by setting a comparator in SearchableListModel: http://gerrit.ovirt.org/#/c/15846/ If a comparator isn't set, then everything should behave as before. If a comparator is set, then from that moment on the tab items will be kept in a SortedSet, so that even if an item is added in a way that doesn't trigger an event (e.g. getItems().add()) the items will be kept sorted according to the given comparator. If the comparator is set to null, from that moment on the tab should revert to its old behaviour. You're most welcome to have a look and let me know if this might break something (remember though that it's not obligatory to set a comparator, so only possible breakage should be in generic flows). Feel free to use it once it's merged; along with SortedListModel, this should make sorting less painful. Just keep in mind that once you set a comparator, you can't cast getItems() to a List. This shouldn't be a problem in general, as mostly it's as useful (and probably more correct) to cast to a Collection. Lior. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Sorting in tabs
On 27/06/13 15:37, Einav Cohen wrote: - Original Message - From: Eli Mesika emes...@redhat.com Sent: Thursday, June 27, 2013 6:46:58 AM - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, June 27, 2013 10:12:33 AM Subject: [Engine-devel] Sorting in tabs Hello everyone (UI peeps in particular), I've pushed (not yet merged) a patch that would enable us to keep items in tabs (main/sub) sorted at all times by setting a comparator in SearchableListModel: But tabs includes only 100 records and supports paging , how you deal with that ??? if this is in the GUI level, then I assume that the comparator is simply comparing the items within the current page, and not globally. so the sorting doesn't affect the set of items that is displayed in the page (it would be the same as before the sorting) - just their order. Yes, if I understand correctly how the paging works, Einav is correct - only the items passed to the UI are sorted. also: @Lior - what happens when the search query contains a sort by part? there is a chance that the behaivor would be unexpected in this case; Yes, I thought about this case, and it may result in a confusing user experience if developers aren't careful. Together with the issue of paging, this probably makes this sorting mechanism a better candidate for use within subtabs rather than main tabs. I believe that the correct thing to do is to attach the GUI sorting mechanism to the one in the search mechanism. thoughts? This can be done, however I'm not sure there's much utility in it. Main tabs are always sorted according to some default ordering even if one was not entered in the search panel, and this sorting is also performed consistently with respect to paging. So maybe the right thing to do would be to just block the GUI sorting mechanism for main tabs (i.e. override the setter method and make it no-op)? http://gerrit.ovirt.org/#/c/15846/ If a comparator isn't set, then everything should behave as before. If a comparator is set, then from that moment on the tab items will be kept in a SortedSet, so that even if an item is added in a way that doesn't trigger an event (e.g. getItems().add()) the items will be kept sorted according to the given comparator. If the comparator is set to null, from that moment on the tab should revert to its old behaviour. You're most welcome to have a look and let me know if this might break something (remember though that it's not obligatory to set a comparator, so only possible breakage should be in generic flows). Feel free to use it once it's merged; along with SortedListModel, this should make sorting less painful. Just keep in mind that once you set a comparator, you can't cast getItems() to a List. This shouldn't be a problem in general, as mostly it's as useful (and probably more correct) to cast to a Collection. Lior. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Sorting in tabs
On 27/06/13 16:42, Einav Cohen wrote: - Original Message - From: Lior Vernia lver...@redhat.com Sent: Thursday, June 27, 2013 8:53:59 AM On 27/06/13 15:37, Einav Cohen wrote: - Original Message - From: Eli Mesika emes...@redhat.com Sent: Thursday, June 27, 2013 6:46:58 AM - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, June 27, 2013 10:12:33 AM Subject: [Engine-devel] Sorting in tabs Hello everyone (UI peeps in particular), I've pushed (not yet merged) a patch that would enable us to keep items in tabs (main/sub) sorted at all times by setting a comparator in SearchableListModel: But tabs includes only 100 records and supports paging , how you deal with that ??? if this is in the GUI level, then I assume that the comparator is simply comparing the items within the current page, and not globally. so the sorting doesn't affect the set of items that is displayed in the page (it would be the same as before the sorting) - just their order. Yes, if I understand correctly how the paging works, Einav is correct - only the items passed to the UI are sorted. also: @Lior - what happens when the search query contains a sort by part? there is a chance that the behaivor would be unexpected in this case; Yes, I thought about this case, and it may result in a confusing user experience if developers aren't careful. Together with the issue of paging, this probably makes this sorting mechanism a better candidate for use within subtabs rather than main tabs. note that at some point, I think that we would want to introduce paging also to search- based sub-tabs - it will be useful especially for sub-tabs that potentially display a large number of results (e.g. Disks sub-tab in Storage main tab). In addition, at some point, we would want to get rid of the paging UI as it is now (i.e. next/prev buttons at the top panel) and move to paging triggered by scroll (i.e. have a very long grid, dynamically loaded as you continue to scroll - similar to the behavior of some e-mail web-clients, for example). In this case, sorting on the client side will make no sense at all (i.e. from the user perspective, only a portion of a very large grid will be sorted, the other portions won't be). So for now - yes, I think it makes sense to introduce your mechanism to all sub-tabs, however in the long-term - we would probably want the search-based sub-tabs (which will support paging) to move to search-based sorting, rather than GUI-based-sorting. Sounds good to me. Let me just re-iterate that it is not mandatory to set a comparator, so in technical terms it's not even necessary to introduce it at once to all sub-tabs, if they're already sorting their items some other way. It could happen gradually, and only if developers find it more convenient. In either case, dropping the GUI sorting once search-based sorting is implemented shouldn't be difficult. BTW (maybe the other GUI maintainers can help me with that one) - what about sub-tabs that are not search-based (i.e. display results from a regular query or even from a field within the selected item in the main grid, e.g. Applications in VM) - are these managed via SearchableListModel as well? since the comparator mechanism *is* relevant for them. As far as I've seen, some are managed via SearchableListModel and some aren't. Those that aren't are those that display non-trivial behaviour upon receipt of the items to display (setItems() method) - often this non-trivial behaviour is exactly sorting :) And if it's doing its job, then there's no necessity to change it either. But anyway, I don't know all of them, so I'd also love to hear GUI maintainers. Also: Worth mentioning Bug 893999 - webadmin: please allow column sorting, which requests to enable sorting when clicking on a grid-column header; when implementing column-sorting, probably worth attaching your mechanism to it somehow (i.e. clicking on a column header should set the relevant comparator in the relevant SearchableListModel). I didn't want to say it, because if we upgrade to a newer version of GWT then we could probably use their table column sorting. But this mechanism could allow us to achieve this without upgrading, and it was definitely sitting in the back of my head when I implemented it. All that's needed is, as you said, to listen to table header clicks in the view, and then appropriately set the comparator in the model. I believe that the correct thing to do is to attach the GUI sorting mechanism to the one in the search mechanism. thoughts? This can be done, however I'm not sure there's much utility in it. Main tabs are always sorted according to some default ordering even if one was not entered in the search panel, and this sorting is also performed consistently with respect to paging. So maybe the right thing to do
Re: [Engine-devel] Sorting in tabs
On 27/06/13 18:15, Einav Cohen wrote: - Original Message - From: Lior Vernia lver...@redhat.com Sent: Thursday, June 27, 2013 10:38:04 AM On 27/06/13 16:42, Einav Cohen wrote: - Original Message - From: Lior Vernia lver...@redhat.com Sent: Thursday, June 27, 2013 8:53:59 AM On 27/06/13 15:37, Einav Cohen wrote: - Original Message - From: Eli Mesika emes...@redhat.com Sent: Thursday, June 27, 2013 6:46:58 AM - Original Message - From: Lior Vernia lver...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, June 27, 2013 10:12:33 AM Subject: [Engine-devel] Sorting in tabs Hello everyone (UI peeps in particular), I've pushed (not yet merged) a patch that would enable us to keep items in tabs (main/sub) sorted at all times by setting a comparator in SearchableListModel: But tabs includes only 100 records and supports paging , how you deal with that ??? if this is in the GUI level, then I assume that the comparator is simply comparing the items within the current page, and not globally. so the sorting doesn't affect the set of items that is displayed in the page (it would be the same as before the sorting) - just their order. Yes, if I understand correctly how the paging works, Einav is correct - only the items passed to the UI are sorted. also: @Lior - what happens when the search query contains a sort by part? there is a chance that the behaivor would be unexpected in this case; Yes, I thought about this case, and it may result in a confusing user experience if developers aren't careful. Together with the issue of paging, this probably makes this sorting mechanism a better candidate for use within subtabs rather than main tabs. note that at some point, I think that we would want to introduce paging also to search- based sub-tabs - it will be useful especially for sub-tabs that potentially display a large number of results (e.g. Disks sub-tab in Storage main tab). In addition, at some point, we would want to get rid of the paging UI as it is now (i.e. next/prev buttons at the top panel) and move to paging triggered by scroll (i.e. have a very long grid, dynamically loaded as you continue to scroll - similar to the behavior of some e-mail web-clients, for example). In this case, sorting on the client side will make no sense at all (i.e. from the user perspective, only a portion of a very large grid will be sorted, the other portions won't be). So for now - yes, I think it makes sense to introduce your mechanism to all sub-tabs, however in the long-term - we would probably want the search-based sub-tabs (which will support paging) to move to search-based sorting, rather than GUI-based-sorting. Sounds good to me. Let me just re-iterate that it is not mandatory to set a comparator, so in technical terms it's not even necessary to introduce it at once to all sub-tabs, if they're already sorting their items some other way. It could happen gradually, and only if developers find it more convenient. In either case, dropping the GUI sorting once search-based sorting is implemented shouldn't be difficult. BTW (maybe the other GUI maintainers can help me with that one) - what about sub-tabs that are not search-based (i.e. display results from a regular query or even from a field within the selected item in the main grid, e.g. Applications in VM) - are these managed via SearchableListModel as well? since the comparator mechanism *is* relevant for them. As far as I've seen, some are managed via SearchableListModel and some aren't. Those that aren't are those that display non-trivial behaviour upon receipt of the items to display (setItems() method) - often this non-trivial behaviour is exactly sorting :) And if it's doing its job, then there's no necessity to change it either. But anyway, I don't know all of them, so I'd also love to hear GUI maintainers. Also: Worth mentioning Bug 893999 - webadmin: please allow column sorting, which requests to enable sorting when clicking on a grid-column header; when implementing column-sorting, probably worth attaching your mechanism to it somehow (i.e. clicking on a column header should set the relevant comparator in the relevant SearchableListModel). I didn't want to say it, because if we upgrade to a newer version of GWT then we could probably use their table column sorting. But this mechanism could allow us to achieve this without upgrading, and it was definitely sitting in the back of my head when I implemented it. All that's needed is, as you said, to listen to table header clicks in the view, and then appropriately set the comparator in the model. [Vojtech/GUI-maintainers - your input would be appreciated here] we are actually planning on upgrading the GWT version *really* soon (to GWT 2.5), so my question is: should we wait until the new GWT is introduced, and implement client-sorting based on the GWT-grid-widget
Re: [Engine-devel] oVirt 3.2 test-day
I'll be participating and testing the network scenarios (added to wiki). On 29/01/13 01:30, Moran Goldboim wrote: we were supposed to have test day tomorrow, but we decided to push it to Thursday (Jan 31) to have ovirt-node and proper infra for test day (Mike should announce it's officially soon). I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there is action from your part as well: -go over the scenarios (regressions), see if those relevant, add more if needed remove if not. -add basic tests for your new 3.2 features. -assign a contributor to be actively present on helping users on his area -make commitment and participate the test day I would like to review this document by Wednesday on users meeting, please make sure your part is updated by than. Thanks, Moran. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
