[ovirt-devel] oVirt weekly sync cancelled this week (June 4th)
Hi all, due to various holidays this week the weekly oVirt sync will be cancelled and we'll meet next week (June 11th). Doron ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] New Stats for oVirt Community
The folks at Bitergia have been working on improving the community metrics dashboard located at ovirt.org/stats. I was just notified that, per our request, metrics for a big asset in our community--the #ovirt IRC--have been added to the dashboard. Swing by the page and see who's active on IRC and in the rest of the oVirt community! Peace, Brian -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC ___ 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(CollectionT value) method. You will notice that eventually all the items are added to a SortedSet. This is not a problem if all the elements of your collection are different. But what happens if the elements of your collection are not all different. More specifically if I pass in a comparator that matches on a field of the object that is not different like description, or size or something of that nature. The set will reduce the number of elements. Before I change it to be a list that can have duplicates, I would like to know the origin of the set and if there are going to be any issues when I do that. It was originally conceived as a way to consistently keep items in a sorted manner, whether they're added via setItems() or getItems().add(). It had nothing to do with the fact that duplicates aren't allowed, so I doubt a change will adversely affect current uses (of which there aren't many, if I'm not mistaken, so it's better to verify). However, a list doesn't automatically sort itself as items are added, so you should preserve that functionality if you decide to change the implementation. You could implement a customized List that invokes sort() upon add(). I think the current implementation is far more efficient in that insertion and removal is done in O(logn), whereas the alternative would be O(n). You might say that's not important, I think it might be important for scalability in the future. Personally I think that having correct behavior is more important than having incorrect but fast behavior. Basically the set works fine if you use the natural order of the objects. However if you pass in a different Comparator the set falls apart as you now potentially have duplicates based on the Comparator. A good example is entities with a description or comment field. If I pass in a Comparator that simply compares the description field of the entities, I can and do have duplicates. The resulting collection is now smaller than the original which is obviously not what we want. First of all, I'm not sure that description and comment are useful columns to sort by. Secondly, I saw you mentioned in another thread that you were using a compound comparator with a secondary property to sort by - I think this is a very correct solution, and actually something we should do regardless of the issue you raised; otherwise on refresh items could switch places. So I would try to have comparators enforce a consistent ordering (i.e. never return 0). By the way, a good secondary sort property would be the item's position in the collection prior to sorting. This would enable users to implicitly define secondary (and tertiary, etc.) sort criteria, according to the order in which they clicked on column headers. And of course it satisfies consistency. When I get to the network-related sorting (next couple of days) I'll see if I can design a nice shareable utility to help with that and put it in the Linq class. You are right that I will be unable to force a sort when someone does a getItems.add. There seems to be only one data structure in java that is automatically sorted on adds as well as allows for duplicate entries, which is a PriorityQueue. Since we are using Collections this should not be a problem, however if anyone casts it to a list, it will explode. ...or SortedSet, which is why it was used :) And which would also explode if cast to List. Which is okay because ListModel only guarantees a Collection to be returned - casting to List isn't great practice. There is the other choice of using a customized List in ListModel, which would work perfectly fine. But if comparators are constructed so that they never return 0, as discussed above, this becomes a non-issue. But frankly, it's not difficult to notice what one inserts into their SortedListModel, and to make sure that its equals() method is consistent with what they're trying to achieve (or wrap the items in case it isn't). Thanks, Alexander ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Updated infra procedures
- Original Message - From: David Caro dcaro...@redhat.com To: us...@ovirt.org, devel@ovirt.org, infra in...@ovirt.org Sent: Thursday, May 29, 2014 8:50:58 PM Subject: [ovirt-users] Updated infra procedures Hi everyone! From now on we want and to be able to give the best response possible to any issue, we want to start using trac to manage any request we get, so from now on, please open a ticket in the trac [1] whenever you need something to get done, of course, if you ping us on irc we will still respond and if it's a critical issue or a very trivial one we might solve it on the fly, but for any normal infra issue please open a trac ticket. The wiki page has been updated with that information too (thanks eyal) [2] np, +1 for the initiative, i think infra team can provide much better support, if all issues will be reported via the trac. thanks, Eyal. [1] https://fedorahosted.org/ovirt/newticket [2] http://www.ovirt.org/Category:Infrastructure#How_we_work Thanks! -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ 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] 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] how to call the SW part of instance type?
- Original Message - From: Lior Vernia lver...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: devel@ovirt.org Sent: Monday, June 2, 2014 1:26:34 AM Subject: 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. IIRC we already have VM payload. 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 +1 on that one (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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
