I would like to propose Yedidyah Bar David as oVirt Hosted Engine Setup co-maintainer.
Yedidyah contributed to oVirt Hosted Engine Setup since early design phase and contributed dozens of patches.
Your response would be appreciated.
Thanks in advance.
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
I just stumbled upon a defunct supervdsm process:
root 2824 2815 0 Apr04 ? 00:01:01 /usr/bin/python
/usr/share/vdsm/supervdsmServer --sockfile /var/run/vdsm/svdsm.sock
qemu 31321 2824 0 May02 ? 00:00:00 [supervdsmServer] <defunct>
any chance to debug this?
might this be an instance of this closed (but never fixed) bug?
Mit freundlichen Grüßen / Regards
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
I have a feeling there is some inconsistency in using entity names in the DB scripts.
For example, should we use Host or VDS?
I am not talking about existing tables or columns but about new ones (and new stored procedures).
I am quite sure I saw patches containing both approaches.
I'm running some tests with Raspberry Pi, trying to use it as a thin
client to oVirt.
My initial test was just open web User Portal using a browser. But
RasPi limited performance is leading browser to repeatedly show the
warning for "unresponsive script" before load the portal.
Trying to have a lighter way to access oVirt with the same functions
as in "Basic" User Portal, I wrote this Python-GTK client. Its
performance in RasPi is quite acceptable currently.
I'm wondering if you guys have any interest in putting the bits
somewhere along with the project repositories. Maybe in
Here a screenshot with it in action:
in the instance type feature  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".
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)
Do we need to support a format of user name like "profile\user" for REST-API authentication? (if you're not familiar with the term profile, I can ask the same about "domain\user"
I see in the code it exists, but I was wonder whether it is really needed.
Thanks for any thoughts on this,
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).
I have a question about the SortedListModel. If you look at the
setItems(Collection<T> 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.