VDSM sync meeting minutes December 9th, 2014
by Dan Kenigsberg
- Everybody should review Piotr's
http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:...
and approve the API of their respective component.
Francesco: virt
Nir: storage
Adam: live{merge,snapshot}, mother patch
Ido: network
- Nir suggest to generate API from schema (or vice versa) instead of verifying
that the duplicated API definition is consistent.
Adam agrees that API.py can go away; but that Piotr's work is helpful sanity
check for the short term.
- F21 needs testing. Petr Horacek reports that vdsmd works exteremely
slowly when started via systemd on Fedora 21. Please report to this
list if you have good/bad experience with it.
- el6 nearing its end of support. clusterLevel 3.6 features would be
limitted to el7.
- Adam suggests to tag legacy code with
# REQUIRED_FOR: el6
Or
# REQUIRED_FOR: engine-3.0
So it is easier to find and drop when we remove support of legacy
platform or legacy client.
- Nir and Federico to review Amador's iscsiadm.iface_list()
http://gerrit.ovirt.org/35807 and follow-up patches.
Dan
9 years, 11 months
Question about emulating ARM using oVirt
by Richard Chapman
--_000_d4def217330a4755862e229ac6fd32c4IPESRVMAILipesystemsloc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi and just wanted to say love oVirt.
I'm using oVirt 3.5 on Fedora20 to help with are devel/testing needs. Are s=
oftware runs on top of Linux both in Intel and ARM platforms. While oVirt =
can handle very well the intel side of things I still need to run everythin=
g on ARM on real hardware. What I'm wondering is there a plan to support at=
least ARM emulation using QEMU now libVirt has been fixed.
Thank
Chapman....
--_000_d4def217330a4755862e229ac6fd32c4IPESRVMAILipesystemsloc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi and just wanted to say love oVirt. <o=
:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">I’m using oVirt 3.5 on Fedora20 to help with a=
re devel/testing needs. Are software runs on top of Linux both in Intel and=
ARM platforms. While oVirt can handle very well the intel side of th=
ings I still need to run everything on ARM on
real hardware. What I’m wondering is there a plan to support at leas=
t ARM emulation using QEMU now libVirt has been fixed. <o:p></o:p></p=
>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Thank<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Chapman….<span style=3D"mso-fareast-language:E=
N-GB"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>
--_000_d4def217330a4755862e229ac6fd32c4IPESRVMAILipesystemsloc_--
9 years, 11 months
3.5.1 RC schedule [was Re: [ovirt-users] oVirt Weekly Sync Meeting: Dec. 10, 2014]
by Sandro Bonazzola
Il 10/12/2014 16:54, Brian Proffitt ha scritto:
> (On time this week!)
>
> =========================
> #ovirt: oVirt Weekly Sync
> =========================
[cut]
> * 3.5.z updates Two blockers have postponed RC again. New RC date will
> be discussed and decided in mailing list. (bkp, 15:30:01)
[cut]
Let's start the discussion and decision task.
We have an ETA on the last pending blocker for 3.5.1 on next week.
I suggest to postpone RC and GA after winter holidays.
What about:
RC - 2015-01-07
GA - 2015-01-14
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 11 months
[UI] Start/stop progress automatically
by Lior Vernia
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/
9 years, 11 months
A Question about Ovirt-engine Stage_Customization_setup Interface
by 穆骏
------=_Part_426046_1993880784.1418364819377
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64
QWJvdXQgdGhlIGludGVyYWN0aW9uIHN0eWxlIG9mIGVuZ2luZS1zZXR1cCAsaSB3YW50IHRoZSBp
bnRlcmZhY2Ugd2hpY2ggcHJlc2VudCB0byB1c2VyIHdpbGwgYmUgYSBmb3JtLCBsaWtlIHdlYiBs
b2dpbiBmb3JtIG9yIHJlZ2lzdGVyIGZvcm0sIApVc2VyIGZpbGwgdXAgdGhlIGZvcm0gYW5kIGNs
aWNrIHNhdmUgdGhlbiB0aGUgc2V0dXAgcHJvY2VzcyBnbyB0byB0aGUgbmV4dCBzdGFnZSAgLiBN
eSBwcm9ibGVtIGlzIHdoZW4gaSBicmluZyBpbiB0aGUgVFVJIHBhY2thZ2UgbGlrZSB1cndpZChC
YXNlZCBvbiB0aGUgZXZlbnQgbG9vcCwgd2hpY2ggaXMgdXNlZCBieSBvdmlydC1ub2RlLjMuNS4w
ICkgdG8gcmVwbGFjZSB0aGUgb3JpZ2luYWwgZGlhbG9nIEltcGxlbWVudGF0aW9uIG9mIG90b3Bp
LAppIGZvdW5kIHRoYXQgaSBoYXZlIHRvIGNoYW5nZSBhIGxvdCAsbm90IG9ubHkgdGhlIG9yaWdp
bmFsIGRpYWxvZyBJbXBsZW1lbnRhdGlvbiBidXQgYWxzbyB0aGUgcHJvY2VzcyB0aGF0IHZhbGlk
YXRlIGFuZCBzYXZlIGN1c3RvbSBjb25maWcuCklzIHRoZXJlIGEgc2ltcGxlIHdheSB0byB3b3Jr
IGFyb3VuZCB0aGUgcHJvYmxlbSA/ICBUaGFuayB5b3Ugc28gbXVjaC4=
------=_Part_426046_1993880784.1418364819377
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64
PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMy43OTk5OTkyMzcw
NjA1cHg7Ij48c3BhbiBpZD0idHJhbl8yXzMiIGNsYXNzPSIiIHN0eWxlPSJjb2xvcjogcmdiKDY3
LCA2NywgNjcpOyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGxpbmUtaGVpZ2h0OiAy
NHB4OyI+QWJvdXQgdGhlIGludGVyYWN0aW9uIHN0eWxlIG9mIGVuZ2luZS1zZXR1cCAsaSB3YW50
IHRoZSBpbnRlcmZhY2Ugd2hpY2ggcHJlc2VudCB0byB1c2VyIHdpbGwgYmUgYSBmb3JtLCBsaWtl
IHdlYiBsb2dpbiBmb3JtIG9yIHJlZ2lzdGVyIGZvcm0sJm5ic3A7PC9zcGFuPjwvZGl2PjxkaXYg
c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMy43OTk5OTkyMzcwNjA1cHg7Ij48c3BhbiBjbGFzcz0iIiBz
dHlsZT0iY29sb3I6IHJnYig2NywgNjcsIDY3KTsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl
cmlmOyBsaW5lLWhlaWdodDogMjRweDsiPlVzZXIgZmlsbCB1cCB0aGUgZm9ybSBhbmQgY2xpY2sg
c2F2ZSB0aGVuIHRoZSBzZXR1cCBwcm9jZXNzIGdvIHRvIHRoZSBuZXh0IHN0YWdlICZuYnNwOy4g
TXkgcHJvYmxlbSBpcyB3aGVuIGkgYnJpbmcgaW4gdGhlIFRVSSBwYWNrYWdlIGxpa2UgdXJ3aWQo
QmFzZWQgb24gdGhlIGV2ZW50IGxvb3AsIHdoaWNoIGlzIHVzZWQgYnkgb3ZpcnQtbm9kZS4zLjUu
MCApIHRvIHJlcGxhY2UgdGhlIG9yaWdpbmFsIGRpYWxvZyZuYnNwOzxzcGFuIHN0eWxlPSJjb2xv
cjogcmdiKDk5LCAxNDAsIDExKTsiPkltcGxlbWVudGF0aW9uIG9mIG90b3BpPC9zcGFuPiw8L3Nw
YW4+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIzLjc5OTk5OTIzNzA2MDVweDsiPjxz
cGFuIGNsYXNzPSIiIHN0eWxlPSJjb2xvcjogcmdiKDY3LCA2NywgNjcpOyBmb250LWZhbWlseTog
QXJpYWwsIHNhbnMtc2VyaWY7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+aSBmb3VuZCB0aGF0IGkgaGF2
ZSB0byBjaGFuZ2UgYSBsb3QgLG5vdCBvbmx5IHRoZSBvcmlnaW5hbCZuYnNwOzwvc3Bhbj48c3Bh
biBzdHlsZT0iY29sb3I6IHJnYig2NywgNjcsIDY3KTsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z
LXNlcmlmOyBsaW5lLWhlaWdodDogMjRweDsiPmRpYWxvZyZuYnNwOzwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBsaW5lLWhlaWdodDogMjRweDsgY29s
b3I6IHJnYig5OSwgMTQwLCAxMSk7Ij5JbXBsZW1lbnRhdGlvbiBidXQgYWxzbyB0aGUgcHJvY2Vz
cyB0aGF0IHZhbGlkYXRlIGFuZCBzYXZlIGN1c3RvbSBjb25maWcuPC9zcGFuPjwvZGl2PjxkaXYg
c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMy43OTk5OTkyMzcwNjA1cHg7Ij48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBsaW5lLWhlaWdodDogMjRweDsgY29sb3I6IHJn
Yig5OSwgMTQwLCAxMSk7Ij5JcyB0aGVyZSBhIHNpbXBsZSB3YXkgdG8gd29yayBhcm91bmQgdGhl
IHByb2JsZW0gPyAmbmJzcDtUaGFuayB5b3Ugc28gbXVjaC48L3NwYW4+PC9kaXY+PC9kaXY+
------=_Part_426046_1993880784.1418364819377--
9 years, 11 months
Call for Presentations: OSCON 2015
by Brian Proffitt
OSCON is returning to Portland July 20-24, 2015, and we want to make sure it's on your radar. As you probably know, the O'Reilly Open Source Convention is the must-attend professional training event for 4,000+ developers, programmers, engineers, architects, CxOs, and technology innovators. OSCON is well known for a fast-paced, intellectually stimulating program, that covers the open source ecosystem in its entirety. The call for speakers has just opened. If you, or any of your colleagues, are interested in speaking at OSCON, please review the new and improved program themes and tracks at OSCON.com, and find out about the kinds of topics we’re looking for, as well as tips for creating a great proposal.
Proposals are due by February 2, 2015.
http://www.oscon.com/open-source-2015
--
Brian Proffitt
Community Liaison
oVirt
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC
9 years, 11 months
Really slow VDSM on F21
by Petr Horacek
Hello,
has anyone else noticed VDSM's problems on Fedora 21?
The problem is that when I start vdsmd via systemd, it takes
about a minute to start the listener (returning Connection
to 0.0.0.0:54321 refused) and next few minutes it returns
'Recovering from crash or Initializing'. After that, `getVdsCaps`
takes cca 20 secs to finish.
I tried to change niceness in vdsmd.service but it's still the same.
When I start vdsm directly (/usr/share/vdsm/vdsm as vdsm user) it
starts within a second as it should.
Have you an idea why this happens?
Best regards,
Petr
9 years, 11 months
Creating a new gerrit flag
by David Caro
--I33OQG5IFrqF2BWt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi!
e have been having an issue with gerrit patches being merged before
jenkins ran any tests on them, to avoid it from happening again I
propose creating a new gerrit flag (Tests) with the following
specifics:
+1 - Tests passed/overrided
0 - Tests pending
-1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when
passing the tests and -1 is set by jenkins in case it breaks any
tests. The +1 flag can be set also by maintainers to allow overriding
the process.
That way all the tests will be blocked until someone (hopefully
jenkins) adds the +1 flag, but if the maintainer wants to override the
value, she just has to set that flag herself.
What do you think?
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--I33OQG5IFrqF2BWt
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUhsQoAAoJEEBxx+HSYmnDhEAH/jWxTaroG11HCl6Ke547iHXl
JS8sr8OF2Vc/D4iNgkopb+ZAM67tsT2DP/q3BtBLz34LlWiIiTgNOmW9Gve+0osM
kXzyeTc2ZcyjCF2nvCazZm1hC0WKtgERGfc6wmULyUBgYySF9X0mznNdoWRANCfu
CKreZx9KqfiSjGWXsEfog5ETJSX+luolpHzYi0nd9ZLuHKm76Edqn9b6X+CVewS5
Ev0vGmt/qdUDwM3sSPmp4hFVyGBQ/1vvnFgqvSSCp1WwEuFsyM7ctMKtsE0IotrB
Tvwc2B3TWTpbKVTsaaiHSAjkRjiqiR6j4h5sEKagBUHhATxdq+7Z3jYZHM0Fn0I=
=ZGaS
-----END PGP SIGNATURE-----
--I33OQG5IFrqF2BWt--
9 years, 11 months
where vm obeject be deleted from vmContainer when shutdown
by zhangjian2011
Hi, Guys
I am studying ovirt, and now I am checking how vdsm manage VM.
But now I have a trouble about the process "shutdown VM".
I know that when start up a VM, a vm object will be added to the
vmContainer.
And I think the vm object will be deleted from vmContainer when
shutdown/poweroff since
the code will check whether the vm object exist in vmContainer when
start up VM.
---------------------------------
# cat vdsm/API.py
def create(self, vmParams):
"""
Start up a virtual machine.
:param vmParams: required and optional VM parameters.
:type vmParams: dict
"""
vmParams['vmId'] = self._UUID
try:
if vmParams.get('vmId') in self._cif.vmContainer:
self.log.warning('vm %s already exists' % vmParams['vmId'])
return errCode['exist']
... snip ...
---------------------------------
I found the vm object will be deleted from vmContainer when poweroff.
but I did not find where vm obeject be deleted from vmContainer when
shutdown.
Does someone can help me?
---------------------------------
# cat vdsm/virt/vm.py
def destroy(self):
self.log.debug('destroy Called')
response = self.doDestroy()
if response['status']['code']:
return response
# Clean VM from the system
self.deleteVm()
... snip ...
def deleteVm(self):
"""
Clean VM from the system
"""
try:
del self.cif.vmContainer[self.conf['vmId']]
self.log.debug("Total desktops after destroy of %s is %d",
self.conf['vmId'], len(self.cif.vmContainer))
except Exception:
self.log.error("Failed to delete VM %s", self.conf['vmId'],
exc_info=True)
... snip ...
---------------------------------
Regards,
Jian
--
--------------------------------------------------
Zhang Jian
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China
TEL: +86+25-86630566-8526
FUJITSU INTERNAL: 7998-8526
FAX: +86+25-83317685
MAIL: zhangjian2011(a)cn.fujitsu.com
--------------------------------------------------
9 years, 11 months
[QE][ACTION REQUIRED] oVirt 3.5.1 RC status
by Sandro Bonazzola
Hi,
We have still blockers for oVirt 3.5.1 RC release so we need to postpone it until they'll be fixed.
ACTION: Being so near to winter's holidays we need to discuss the new tentative date for RC in today sync meeting.
The bug tracker [1] shows 2 open blocker:
Bug ID Whiteboard Status Summary
1160846 sla NEW Can't add disk to VM without specifying disk profile when the storage domain has more than one disk profile
1168709 virt NEW Hosted Engine VM is listed as paused after upgrading from 3.4.4 to 3.5.1 snapshot
In order to stabilize the release a new branch ovirt-engine-3.5.1 will be created from the same git hash used for composing the RC.
- ACTION: assignee please provide ETA on above blockers
Maintainers:
- Please be sure that 3.5 snapshot allow to create VMs
- Please be sure that no pending patches are going to block the release
- If any patch must block the RC release please raise the issue as soon as possible.
There are still 63 bugs [2] targeted to 3.5.1.
Excluding node and documentation bugs we still have 42 bugs [3] targeted to 3.5.1.
Maintainers / Assignee:
- Please add the bugs to the tracker if you think that 3.5.1 should not be released without them fixed.
- ACTION: Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1:
it will ease gathering the blocking bugs for next releases.
- ACTION: Please fill release notes, the page has been created here [4]
Community:
- If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5]
[1] http://bugzilla.redhat.com/1155170
[2] http://goo.gl/7G0PDV
[3] http://goo.gl/6gUbVr
[4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes
[5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 11 months
