I've had some questions about the Google Summer of Code, and I wanted to
share with you the dates and milestones for the student/mentor onboarding
phase of the event. All dates can be found on the GSoC site.
Right now we are in the student application phase, which goes until April
3. By that time, students should have their draft proposals in. Then we
review them and turn them in to Google by April 16. On April 17, we ask for
student slots, and then on April 19, slots are allocated to us.
Finally, on April 24, we tell Google which students are going to take the
slots, and then on May 3, Google announces all projects/students/mentors.
Hopefully this helps. Please watch your inbox for notifications from Google
to ensure what you are getting does not need an action item. What I get as
one of the oVirt admins for GSoC is different that what you get as
Principal Community Analyst
Open Source and Standards
I'll be performing a planned Jenkins restart within the next hour.
No new builds will be scheduled during this maintenance period.
I will inform you once it is over.
Test failed: [ test-repo_ovirt_experimental_master ]
Link to suspected patches: N/A
Link to Job:
Link to all logs:
Error snippet from the log:
2017-03-21 11:55:15,975-0400 ERROR (jsonrpc/7) [storage.TaskManager.Task]
(Task='02a8b5a3-ff82-4a07-bc8a-b3a756630e8c') Unexpected error (task:871)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 878,
return fn(*args, **kargs)
File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 52, in
res = f(*args, **kwargs)
File "/usr/share/vdsm/storage/hsm.py", line 1158, in attachStorageDomain
File "/usr/lib/python2.7/site-packages/vdsm/storage/securable.py", line
79, in wrapper
return method(self, *args, **kwargs)
File "/usr/share/vdsm/storage/sp.py", line 930, in attachSD
dom = sdCache.produce(sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 112, in produce
File "/usr/share/vdsm/storage/sdc.py", line 53, in getRealDomain
File "/usr/share/vdsm/storage/sdc.py", line 136, in _realProduce
domain = self._findDomain(sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 153, in _findDomain
File "/usr/share/vdsm/storage/sdc.py", line 178, in _findUnfetchedDomain
StorageDomainDoesNotExist: Storage domain does not exist:
Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
RHCSA | RHCVA | RHCE
IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)
OPEN SOURCE - 1 4 011 && 011 4 1
I just merged a large patch that does a complete visual update of all dialogs
in oVirt. All the dialogs should now follow the standard patternfly modal
dialog visuals and layout. One of the consequences of this is that you can no
longer move the dialogs around in the application like before. This is by
I tried very hard to make sure I updated every dialog in the application to
match the look and feel as needed, or at the very least did not display any
major issues like missing content or extra scrollbars where none were needed.
Please report any issues you find to me, and I will try to make sure they get
ps. attached are some screenshots from my development environment.
On 03/17/2017 11:07 PM, Michal Skrivanek wrote:
>> On 17 Mar 2017, at 15:57, Francesco Romani <fromani(a)redhat.com> wrote:
>> On 03/16/2017 08:03 PM, Francesco Romani wrote:
>>> On 03/16/2017 01:26 PM, Francesco Romani wrote:
>>>> On 03/16/2017 11:47 AM, Michal Skrivanek wrote:
>>>>>> On 16 Mar 2017, at 09:45, Francesco Romani <fromani(a)redhat.com> wrote:
>>>>>> We talked about sending storage device purely on metadata, letting Vdsm
>>>>>> rebuild them and getting the XML like today.
>>>>>> In the other direction, Vdsm will pass through the XML (perhaps only
>>>>>> parts of it, e.g. the devices subtree) like before.
>>>>>> This way we can minimize the changes we are uncertain of, and more
>>>>>> importantly, we can minimize the risky changes.
>>>>>> The following is a realistic example of how the XML could look like if
>>>>>> we send all but the storage devices. It is built using my pyxmlpickle
>>>>>> module (see  below).
>>>>> That’s quite verbose. How much work would it need to actually minimize it and turn it into something more simple.
>>>>> Most such stuff should go away and I believe it would be beneficial to make it difficult to use to discourage using metadata as a generic junkyard
>>>> It is verbose because it is generic - indeed perhaps too generic.
>>>> I can try something else based on a concept from Martin Polednik. Will
>>>> follow up soon.
>>> Early preview:
>>> still plenty of TODOs, I expect to be reviewable material worst case
>>> monday morning.
>> This is how typical XML could look like:
>> <ovirt-tune:qos />
>> <ovirt-vm:vm />
> not under the <ovirt-vm:vm>?
> any reason?
No reason, I'll move under it
Red Hat Engineering Virtualization R & D
Hi oVirt developers,
A few weeks ago we announced that it is now possible to run oVirt System
Tests on any open patch in oVirt .
Just wanted to remind everyone how easy it to run the whole basic suite or
upgrade suite on your open patches.
Here is a summary of the steps needed to run the job :
*How to use?*
Add a comment to your open patch in Gerrit and write '*ci please build*'
Wait for the 'build-on-demand' job to finish and copy the URL of
the build that shows up on the comments in Gerrit.
Go the manual job  and click 'Build with parameters' 
Add your 'build-on-demand' URLs to the job (you can put multiple
URLs, one per line)
Choose the oVirt version you wish to test (should match to the
oVirt version of your patch).
Choose the suite type from the drop-down menu (choose basic to run
normal sanity or upgrade to test upgrade engine)
There are other options to choose, but the default ones will work best
for most cases,
You can checkout the documentation  for more detailed info.
Feel free to reach out to infra team for more info or help!
 make sure you have the 'dev' role for Jenkins, if you don't, send email
to infra-support(a)ovirt.org and ask to be added.
EMEA ENG Virtualization R&D
Red Hat Israel
irc: eedri (on #tlv #rhev-dev #rhev-integ)