Re: [ovirt-devel] Validation issue with IntegerEntityModelTextBoxEditor
On 30/04/15 15:03, Tomas Jelinek wrote: > > > - Original Message - >> From: "Lior Vernia" >> To: "Ramesh" >> 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] 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... 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
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" > To: "Sandro Bonazzola" > Cc: "Amit Aviram" , "Yedidyah Bar David" > , "Ido Barkan" , "Martin Perina" > , "Tal Nisan" , "Maor Lipchuk" > , "Eyal Edri" , 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:
>
>
>
>href="/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/setupnetworks"
> rel="setupnetworks"/>
>
> href="/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a"
> id="10070ac3-174a-4cf4-a774-8aed432a909a">
>
> href="/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/attach"
> rel="attach"/>
> href="/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/detach"
> rel="detach"/>
>
> em1
> href="/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/statistics"
> rel="statistics"/>
> href="/api/hosts/07915908-72ac-4fd9-8aef-e9dd3194981d/nics/10070ac3-174a-4cf4-a774-8aed432a909a/labels"
> rel="labels"/>
> id="07915908-72ac-4fd9-8aef-e9dd3194981d"/>
>
>none
>up
>1500
>false
>
>
>
> [root@livecd ~]# ip addr
> 1: lo: 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: 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: mtu 1500 qdisc noop state DOWN
> link/ether ba:29:75:10:37:7e brd ff:ff:ff:ff:ff:ff
> 4: ovirtmgmt: 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;: 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 /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt
> DEVICE=ovirtmgmt
> TYPE=Bridge
> DELAY=0
> STP=off
> ONBOOT=yes
> IPADDR=10.0.0.1
> NETMASK=255.255.255.0
> GATEWAY=10.0.0.1
> BOOTPROTO=none
> MTU=1500
> DE
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',
>
Re: [ovirt-devel] Reference implementation of events
On 09/02/15 17:23, Piotr Kliczewski wrote: > Hi, > > As you may know I currently work on event infrastructure which will > let vdsm push information to the engine. I already pushed some drafts > providing event functionality and started to think which part of > engine <-> vdsm interaction could be changed to events. The goal is to > build usable api for it as well as provide example how to migrate > other parts of code to events. > > Initially we started to look at VM.getStats [1] but we still want to > have Host.getAllVmStats run by quartz job. I had a chat with Vinzenz > about the structure and frequency of data change for VM.getStats and > it seems that the data changes ~2s so this verb is not the best choice > to send events with deltas containing the change since we are polling > every 3s for the information. > > We started to explore which data generated by vdsm/guest agent could > be sent as events and he pointed me to [2]. > > I would like to trigger discussion about how to dived data to maximize > benefits of sending events with deltas and for some parts of data keep > polling functionality as it is now. > > Do you have any suggestion which verb we could safely use as reference > implementation for events? I'm not sure what you mean by "safely", but a good candidate (in terms of both low frequency of changes and value of triggered events) would be getVdsCaps. Especially if only deltas are sent. For example, we'd love get relevant data from vdsm whenever a network interface's IP address changes (an event which phoracek is currently working on monitoring). That's one example I know from networking, but maybe such examples exist where the monitoring is already implemented and ready to be tested via event triggering. > > Thanks, > Piotr > > [1] http://gerrit.ovirt.org/#/c/37488/ > [2] http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > ___ > 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] 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:
>
>
>
> ...
> ...
> ...
>
>
>
> ...
>
>
>
>
> 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" >> To: "Sahina Bose" , "Allon Mureinik" >> , "Arik Hadas" , >> "Mike Kolesnik" , "Gilad Chaplik" >> Cc: "engine-de...@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] oVirt 3.6 Feature: Cumulative Network Usage Statistics
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? >> >> Note that this only deals with network usage - it'll be great if we have >> similar features for CPU and disk usage! > > There's a formal feature request about this: > Bug 1172153 - [RFE] Collect CPU, IO and network accounting > information > > Dan > ___ 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" >> To: "Dan Kenigsberg" >> Cc: "engine-de...@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" >>> To: "Oved Ourfali" >>> Cc: "engine-de...@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" >>>>> To: "Oved Ourfali" , fsimo...@redhat.com >>>>> Cc: "engine-de...@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" >>>>>>> To: "Lior Vernia" , "Oved Ourfali" >>>>>>> >>>>>>> Cc: "engine-de...@ovirt.org" , "Dan Kenigsberg" >>>>>>> , "Yaniv Bronheim" >>>>>>> >>>>>>> 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" >>>>>>>> To: "Eli Mesika" >>>>>>>> Cc: "engine-de...@ovirt.org" , "Dan Kenigsberg" >>>>>>>> , "Yaniv Bronheim" >>>>>>>> >>>>>>>> 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:21, Sahina Bose wrote: > > On 01/12/2015 08:52 PM, Dan Kenigsberg wrote: >> On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote: >>> >>> 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. >> In the suggested feature, there is no real storage "role". The "storage >> role" title means only "default value for glusterfs IP". >> >> For example, once a brick was created, nothing protects the admin from >> accidently removing the storage network, or changing its IP address. >> >> Another "proof" that this is not a real "role", is that it affects only >> GUI: I am guessing that REST API would not make use of it at all. (maybe >> I'm wrong; for sure, REST must be defined in the feature page) > > REST API that lists the available networks (with IP addresses) would be > used to select the network and pass to the create gluster volume API > > I'll update the feature page with the REST API changes as well. > If REST allows to choose the network used for gluster traffic, then I think so should the GUI - I would not drop the list box from the design in that case. >> >> Maybe that's the behavior we want. But alternatively, Engine can enforce >> a stronger linkage between the brick to the network that it uses. When >> adding a brick, the dialog would list available networks instead of the >> specific IP. As long as the brick is being used, the admin would be >> blocked/warned against deleting the network. > > Is there a way to block against changing IP address used by a network? > Yes, this should be implemented at least in the canDoAction() method of SetupNetworksCommand (most of it is done in the SetupNetworksHelper class). And perhaps this should be blocked in the GUI as well. Note that by the time 3.6 is released, the REST (and probably GUI) are supposed to work with a different backend command that is currently being implemented - so maybe you'll need to modify that instead, or on top of the changes in SetupNetworksHelper. >> >> I'm missing a discussion regarding the upgrade path. If we would opt to >> requiring a single storage role network in a cluster, in an upgraded >> cluster the management network should take this role. > > There would not be any change to existing volumes on upgrade, as bricks > have already been added. Users can use the Edit brick option to update > the network to be used, if required as mentioned in "Change network used > by brick " > I suspect Dan referred to the upgrade path of the engine itself - if you add a new "Gluster Network" boolean column to the DB, it will initially be null for all current networks. You'd likely need to write an upgrade script to assign the role by default to the existing management networks in each cluster. > >> >>>> 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" >>>>> To: devel@ovirt.org, "users" >>>>> Sent: Monday, January 12, 2015 2:00:16 PM >>>>> Subject: [ovirt-users] [Feature review] Select network to be used >>>>> forglusterfs >>>>> >>>>> 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 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" >> To: devel@ovirt.org, "users" >> 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] [ovirt-users] [Feature review] Select network to be used for glusterfs
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. 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. 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] Adding support for 3.6 in engine database
On 08/01/15 15:46, Oved Ourfali wrote: > > > - Original Message - >> From: "Eli Mesika" >> To: "Lior Vernia" , "Oved Ourfali" >> Cc: "engine-de...@ovirt.org" , "Dan Kenigsberg" >> , "Yaniv Bronheim" >> >> 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" >>> To: "Eli Mesika" >>> Cc: "engine-de...@ovirt.org" , "Dan Kenigsberg" >>> , "Yaniv Bronheim" >>> >>> 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? > And as for Eli's question, if I'm not mistaken 4.16 corresponded to 3.5. >> >>> >>> Yours, Lior. >>> >>> On 07/01/15 14:53, Eli Mesika wrote: >>>> Hi >>>> >>>> Please note that 3.6 version support was added to master, default >>>> DC/Cluster are created now with 3.6 and all config changes we applied. >>>> For more information : http://gerrit.ovirt.org/#/c/36518/ >>>> >>>> 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] 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)? Yours, Lior. On 07/01/15 14:53, Eli Mesika wrote: > Hi > > Please note that 3.6 version support was added to master, default DC/Cluster > are created now with 3.6 and all config changes we applied. > For more information : http://gerrit.ovirt.org/#/c/36518/ > > 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] Bump to 3.6 default cluster version
On 01/01/15 15:49, Eli Mesika wrote: > > > - Original Message - >> From: "Lior Vernia" >> To: devel@ovirt.org >> Cc: "Eli Mesika" >> 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
[ovirt-devel] oVirt 3.6 Feature: Cumulative Network Usage Statistics
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 Note that this only deals with network usage - it'll be great if we have similar features for CPU and disk usage! 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] ovirt support ie7 ?
Hello, To the best of my knowledge IE9 and above is supported. To build exclusively for IE9 you could add the following line when running make (see README.developer file in the root your ovirt-engine source directory for reference): DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=ie9" You might try passing ie6 or ie7 instead of ie9 - I have no experience doing this, but even if it's not supported it might "work enough" :) Yours, Lior. On 25/08/14 11:25, Leaboy wrote: > Hi, all: > Does ovirt support IE 7? > If support , how could I build it for IE 7? > > > ___ > 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] [re-posting] [oVirt 3.5 Localization Question #9] "${type} must contain at least one mac range."
Hello Yuko,
It's a good thing you reposted because I did not get the original e-mail!
Yes, this refers to at least one MAC address range. This should be fixed
in the English version as well, we'll get that done while you take care
of the translations :)
Yours, Lior.
On 20/08/14 08:26, Yuko Katabami wrote:
> I am re-posting this as I could not get any response yesterday, and our
> deadline for translation is this Friday.
> It would be greatly appreciated if anyone can answer this question.
>
> Thanks in advance,
>
> Yuko
> On 08/19/2014 05:43 PM, Yuko Katabami wrote:
>> Hello,
>>
>> I would like to check if my interpretation is correct with the
>> following string which was just pushed today.
>>
>> *File: *
>> frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors
>> *Resource ID:* ACTION_TYPE_FAILED_MAC_POOL_MUST_HAVE_RANGE
>> *String: *Cannot ${action} ${type}. ${type} must contain at least one
>> mac range.
>> *Question: *Is "one mac range" referring to "one MAC address range"?
>>
>> Thank you,
>>
>> 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] [oVirt 3.5 Localization Question #10] "{0} greater than or equal to {1}." and "{0} less than or equal to {1}."
Hello Yuko,
These are reasons why a value is considered invalid (i.e. surrounded by
a red border in the GUI).
Yours, Lior.
On 19/08/14 11:26, Yuko Katabami wrote:
> Hello,
>
> Could anyone please clarify the usage of the following strings:
>
> *File: *
> frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/frontend/org.ovirt.engine.ui.uicompat.UIMessages
> *Resource IDs:*
> integerValidationNumberGreaterInvalidReason
> integerValidationNumberLessInvalidReason
> *Strings: *
> {0} greater than or equal to {1}.
> {0} less than or equal to {1}.
> *Question: *Are these strings specifying the requirements for the values
> or is that reason why it is considered to be invalid?
>
> Thank you,
>
> 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
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] Update on UI column sort infra issues
On 27/06/14 15:07, Vojtech Szocs wrote: > Hi guys, > > just a quick update on issues related to UI column sort infra. > > The client-side sorting fix [1] is now merged in master branch. > > The server-side sorting fix [2] is pending review. > > Also note that Lior merged a patch [3] which greatly simplifies > code when making text-based columns *client-side* sortable, for > example: > > TextColumnWithTooltip nameColumn = ... > > instead of this: > > // for text-based columns, need to provide separate Comparator > // that (typically) uses LexoNumericComparator for comparison > nameColumn.makeSortable(someEntityPropertyComparator); > > you can do this: > > // uses LexoNumericComparator to compare column's text values > nameColumn.makeSortable(); > Similar infrastructural patches are pending review: * Checkbox columns - http://gerrit.ovirt.org/#/c/28751/ * Simple status (up/down/none) columns - http://gerrit.ovirt.org/#/c/28753/ * "Identifiable" (interface used by many enums) columns - http://gerrit.ovirt.org/#/c/28755/ * Rx/Tx rate columns (networking statistics in various tabs) - http://gerrit.ovirt.org/#/c/28757/ > -- > > [1] http://gerrit.ovirt.org/#/c/28392/ ... where items would > disappear from grid when activating client-side column sorting > > [2] http://gerrit.ovirt.org/#/c/28557/ ... where triggering > server-side sorting on a given column might corrupt the actual > search query dispatched by the model > > [3] http://gerrit.ovirt.org/#/c/28670/ > > -- > > Regards, > Vojtech > ___ > 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
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-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] Testing backported changes
I use a different DB for each version I'm backporting to, highly recommended. The only (moderate) pain is to reinstall hosts when moving between versions (assuming you're using the same hosts). On 23/06/14 16:47, Kobi Ianko wrote: > Hi, > Is there a nice way to check changes I backported to 3.4.1 without messing my > 3.5 DB? > > 10x > ___ > 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 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 ListModelListBox 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 ListModel). 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" >>> 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" >>>> To: "Lior Vernia" >>>> 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 >
Re: [ovirt-devel] Sortable Ui Columns
On 02/06/14 17:37, Vojtech Szocs wrote: > > - Original Message - >> From: "Alexander Wels" >> To: "Lior Vernia" >> 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/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/SortedListModel.java > > 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. > > What do you think guys? > Preserving the previous ordering will enable users to sort tabs (that are sorted client-side...) according to secondary criteria. Say, for example, I want to have networks grouped by DC, and within each group ordered by name. No problem, I'll just click on the name column header first, then click on the DC column header. Since the DC sorting will preserve the previous ordering for identical DC names, the networks will be sub-ordered by name. I think this is a very cool feature for virtually zero cost. Sub-ordering by hashcode sounds a little random to me. It isn't consistent with any human-comprehensible logic, it is only consistent with Java's default ordering. So if I'm not mistaken, it will only produce predictable results in case a collection isn't explicitly sorted and its items don't implement Comparable. In which case, it will converge to the same result as the "stable" ordering (because ordering will fall back to the original ordering, which was based on hashcode). So it seems to me like the "stable" sub-ordering produces results that are always at least as predictable as hashcode sub-ordering, and in most cases more predictable. >> >> >> [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 t
Re: [ovirt-devel] Sortable Ui Columns
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. 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" > To: devel@ovirt.org > Cc: "Anmol Babu" > 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 of an option as people want automatic sorting when they add new items to > the collection. > 2. Make sure that the comparator never returns 0 for two entities that are > really not the same. The reason you are seeing the issue is because you are > using a different comparator that does return 0 on whatever field you are > comparing against. I had the exact same issue and I solved it by using a > compound comparator. Basically what I did was create a comparator that > contains the field I am trying to compare on and if that returns 0 then I use > a > different comparator that is guaranteed to not return 0 for the entity. > > I have a patch that implements sorting for all the data center main tab and > sub tabs here [1] that demonstrates how I solved the issue. This patch hasn't > been reviewed yet, and my solution might get rejected, but it does work and > doesn't make your entries disappear when you sort. > > > [1] http://gerrit.ovirt.org/#/c/28225/ > > On Friday, May 30, 2014 02:32:17 AM Anmol Babu wrote: >> Hi, >>While applying client-side sort using the sorting infra, to the "Server" >> column of the "Volumes" sub tab "Bricks", I had 2 Bricks with same server >> name.So,when I sorted it, it removed one of the bricks that had the same >> server name. I found that this issue occurs when the sort values compared >> are same(i.e, comparator's compare returns 0). Regards, >> Anmol.B >> ___ >> 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] 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] 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(Collection 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] SortedListModel
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(Collection 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. 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] 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 18:57, Gilad Chaplik wrote:
> - Original Message -
>> From: "Lior Vernia"
>> To: "Gilad Chaplik"
>> Cc: "Vojtech Szocs" , 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"
>>>> To: "Vojtech Szocs"
>>>> 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"
>>>>>> To: "Lior Vernia"
>>>>>> 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"
>>>>>>> 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, defaul
Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 16:02, Gilad Chaplik wrote:
> - Original Message -
>> From: "Lior Vernia"
>> To: "Vojtech Szocs"
>> 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"
>>>> To: "Lior Vernia"
>>>> 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"
>>>>> 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
>>>
&
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"
>> To: "Lior Vernia"
>> 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"
>>> 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 Map, 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.
>>
>>>
>>>
Re: [ovirt-devel] Adjust engine to support arbitrary vlan device name
Hello, I'm just curious as to the restriction mentioned at the bottom of the feature page; it basically means that users who use customized VLAN device name can't perform networking operations from the engine involving those VLAN tags. Can't VDSM locate the proper device according to the VLAN tag and modify it instead of trying to create one with the "default" name? I'm no expert in VDSM, but it sounds like a relatively easy win. Yours, Lior. On 30/04/14 10:54, Alona Kaplan wrote: > Hi all, > > This refactoring is targeted to 3.5. > > Please review the feature page and share your thoughts: > > http://www.ovirt.org/Feature/ArbitraryVlanDeviceName > > Thanks, > Alona > ___ > 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] 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. 2. Modify KeyValueModel to delegate to the common utilities instead of duplicating code, e.g. for validation. 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. 4. Optionally change the implementation of custom properties members in entities (e.g. VM) from String to Map, which would obviate the need for different conversion methods between String/Map - (de)serialization would only be required in DB interaction. 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. However, to my understanding, there's some time until these changes take effect. And even if the frontend is to be written in JavaScript, at least initially the existing frontend code will have to still be used somehow (e.g. auto-translated to JavaScript). That is to say, this refactoring might still be beneficial for the not-so-short term. Before going through with this, I wanted to ask for your thoughts and to hear any specific objections to the proposed changes. Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[Devel] Network custom properties
Hello all, Introducing the oVirt 3.5 feature of network custom properties: http://www.ovirt.org/Features/Network_Custom_Properties Essentially, this feature aims to solve two RFEs, that request the ability to set bridge and ethtool options on host interfaces from the GUI/REST: https://bugzilla.redhat.com/show_bug.cgi?id=1080984 https://bugzilla.redhat.com/show_bug.cgi?id=1080987 It will do so by adding custom properties (key:value pairs) to networks assigned to host interfaces, which can in turn be acted upon via hooks when e.g. a Setup Networks command is triggered. Two predefined keys will include bridge_opts and ethtool_opts, but any arbitrary custom property could be supplied as well. Please take a look at the detailed feature page and let me know if you have any comments. Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
