[Engine-devel] oVirt Weekly Meeting Minutes
by Leonardo Bianconi
Hi Sandro
These are the PPC features and its status:
Target Status Description
3.4 - Under review - Architecture support when importing/exporting VM and Templates
3.4 - Under review - Ability to specify architecture in the OSInfo file
3.4 - Under review - Ability to specify supported video cards and display protocols in the OSInfo file
3.4 - Under review - Ability to specify watch dog in the OSInfo file
3.4 - Done - Ability to specify hotplug of nic and disk in the OSInfo file
3.4 - Under review - Ability to search by architecture
3.4 - Under review - Create Cluster, VM and Templates for PPC64
3.4 - Under review - Add PPC64 Hosts
3.4 - Under review - Support for sPAPR VLAN and sPAPR VSCSI
3.4 - Under review - Run fake power hosts
3.4 - Under review - Obtain capabilities of PPC64 hosts
3.4 - Under review - Obtain the CPU topology of PPC64 hosts
3.4 - Under review - Ability to run power machines on x86 hosts
Some basic patches for PPC support were merged but not enough to enable any PPC feature.
We are focused on the patches 18938, 19010 and 18220 (see below), since they are the base for all PPC features.
Engine
18938 (Initial support for alternative architectures)
|_19010 (Architecture parameter on search backend)
|_18220 (New OS for IBM POWER support)
|_21503 (Architecture dependent commands)
|_21522 (Avoid migration in ppc64)
20294 (Architecture dependent commands)
|_18622 (sPAPR SCSI on PPC64 VMs)
|_20630 (Limit the number of SCSI and VirtIO blk devices)
|_17972 (Show only compatible OSes)
|_18347 (OS type validation)
|_20667 (Fix VM creation with blank template)
|_18702 (Fill and check arch when importing VM and Template)
|_19012 (OVF import for multiple architectures)
|_18226 (Cluster and arch related changes)
|_19132 (Prevent arch mismatches in the FE)
|_18227 (Added arch support for VM and Template)
|_19487 (Selection of incompatible templates)
VDSM
19395 (Hardware information about POWER hosts)
|_17437 (Adding ppc64 handling to getVdsCaps)
|_19396 (Report fake capabilities)
|_18718 (Create VMs for the POWER architecture)
|_19875 (Handling topology for ppc64)
Regards
Leonardo Bianconi
Date: Wed, 27 Nov 2013 17:14:37 +0100
From: Sandro Bonazzola <sbonazzo(a)redhat.com>
To: "Users(a)ovirt.org" <Users(a)ovirt.org>, engine-devel
<engine-devel(a)ovirt.org>
Subject: [Engine-devel] oVirt PPC status update
Message-ID: <52961A6D.4090208(a)redhat.com>
Content-Type: text/plain; charset=ISO-8859-15
Hi,
anybody can report about PPC status for 3.3.2 and 3.4.0 target releases?
It would be nice having someone for PPC at ovirt-sync meeting from next week on, so please join :-)
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
[Engine-devel] [QE] oVirt 3.3.2 beta status
by Sandro Bonazzola
Hi,
we're going to branch and build oVirt 3.3.2 beta TODAY.
A bug tracker is available at [1] and it shows only 3 bugs still blocking the release:
Whiteboard Bug ID Summary
storage 1022961 Running a VM from a gluster domain uses mount instead of gluster URI
virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once
virt 1029885 cloud-init testcase does not work in engine 3.3.1
Please provide an ETA for the above bugs.
The following is a list of the non-blocking bugs still open with target 3.3.2:
Whiteboard Bug ID Summary
infra 1017267 Plaintext user passwords in async_tasks database
infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required,...
infra 1020344 Power Managent with cisco_ucs problem
integration 1022440 AIO - configure the AIO host to be a gluster cluster/host
integration 902979 ovirt-live - firefox doesn't trust the installed engine
integration 1021805 oVirt Live - use motd to show the admin password
integration 1026930 Package virtio-win and put it in ovirt repositories
integration 1026933 pre-populate ISO domain with virtio-win ISO
network 1019818 Support OpenStack Havana layer 2 agent integration
network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider
network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost
network 906313 [oVirt-webadmin] [setupNetworks] "No valid Operation for <network_name> and Unassigned Logical Networks panel"
network 1023722 [oVirt-webadmin][network] Network roles in cluster management should be radio buttons
network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural)
storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output
storage 987917 [oVirt] [glance] API version not specified in provider dialog
storage 1016118 async between masterVersion : can't connect to StoragePool
ux 906394 [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view...
virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain
Please add the bugs to the tracker if you think that 3.3.2 should not be released without them fixed.
For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2].
Maintainers are welcomed to start filling release notes, the page has been created here [3]
[1] https://bugzilla.redhat.com/1027349
[2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
[3] http://www.ovirt.org/OVirt_3.3.2_release_notes
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
[Engine-devel] oVirt PPC status update
by Sandro Bonazzola
Hi,
anybody can report about PPC status for 3.3.2 and 3.4.0 target releases?
It would be nice having someone for PPC at ovirt-sync meeting from next week on, so please join :-)
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
Re: [Engine-devel] [vdsm] Multiple graphics framebuffers - VDSM support
by Frantisek Kobzik
Hi guys,
I created a wiki page with the feature: http://www.ovirt.org/Features/Multiple_Consoles
It contains information about possible redesign of Engine<->VDSM communication.
I'd appreciate if you take a look at it since it's not trivial change.
I welcome opinions from both engine and vdsm devels.
Cheers,
F.
----- Original Message -----
From: "Frantisek Kobzik" <fkobzik(a)redhat.com>
To: vdsm-devel(a)lists.fedorahosted.org
Sent: Monday, November 25, 2013 2:23:59 PM
Subject: Re: [vdsm] Multiple graphics framebuffers - VDSM support
Hi,
it's been some time since the original mail, so I'm sending updated information.
----- Original Message -----
From: "Frantisek Kobzik" <fkobzik(a)redhat.com>
To: vdsm-devel(a)lists.fedorahosted.org
Sent: Thursday, November 7, 2013 11:47:46 AM
Subject: [vdsm] Multiple graphics framebuffers - VDSM support
Dear VDSM developers,
I'm working on a patch that allows running a VM with multiple graphics framebuffers. This is handy when you want to run a VM with both SPICE and VNC. It's a 3.4 feature and it will certainly need a change in vdsm.
Here is a list of changes in VDSM that are needed for this funcionality:
a, Sending graphics/video (engine->vdsm)
- currently we send two things:
1, "display" value (qxl/vnc [wat])
- vdsm uses this for determining if the graphics server is SPICE or VNC
- this attribute is not really correct - it mixes up semantics of graphic
framebuffer and videocard together. I believe this attribute should only
contain information about the graphics ('spice', 'vnc' or 'spice,vnc' if
you want both). if this the case, do you think we should rename the attribute
to, let's say, 'graphics'? Is it even possible with regard to backward
compatibility? or should I reuse 'display' attribute?
2, video device (json representation of the video card) - this is correct
b, Reporting graphics ports (vdsm->engine)
- currently we report 2 graphic ports ('displayPort' and 'secureDisplayPort')
- if we want multiple framebuffers, we must report more ports (for VNC and
SPICE together that would mean 3 ports (2 for spice, one for vnc).
- there are two possible solutions for this:
1, ditch 'displayPort' and 'secureDisplayPort' and add new 'spicePort',
'spiceSecurePort', 'vncPort' fields or some kind of two level dict:
{ protocol -> secured/unsecured -> portNumber }
2, keep 'displayPort' and 'secureDisplayPort' and introduce new 'additionalDisplayPort'
This would be friendlier to backward compatibility, but it's extremely
ugly because of unclear semantics of the fields (in case of SPICE+VNC
'displayPort' and 'secureDisplayPort' would be related to SPICE,
'additionalDisplayPort' would be the VNC port. In case of VNC only, the
'displayPort' would be suddendly VNC port... ewww).
I'd be very happy if you share your opinion about these changes.
Cheers,
Franta.
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
10 years, 4 months
[Engine-devel] failed to add host into cluster
by Chen, Wei D
------=_NextPart_000_0063_01CE8F8D.53576440
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi,
Failed to add a node into cluster. I saw follow hints, but still don't know how to fix it. OS is fedora 19 both for node and engine,
anyone can help me?
Host *** does not comply with the cluster *** emulated machines. The Hosts emulated machines are clipper,none and the cluster is
[rhel6.4.0, pc-1.0]}
Best Regards,
Dave Chen
------=_NextPart_000_0063_01CE8F8D.53576440
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV/jCCBDYw
ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy
dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ
QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha
MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg
RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e
mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe
dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr
TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE
XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV
NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB
BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk
cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0
IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7
rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU
LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD
yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIE6zCC
A9OgAwIBAgIQUukCyhHoRJ2UZTgvoxowuzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTEzMDMxOTAwMDAwMFoX
DTIwMDUzMDEwNDgzOFoweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50
YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVy
bmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDg
sMyAndhJVfoD2wT6OMfdv4XddrzrPcssq7/pa+Mh29RvGejPaqe+X1QpAjewTXNRFDGt+C+0/Rs+
C3W4PAB8tzofl6qfKL7sWs+xMYJHiDAOarVaRNCA0M1dSBvvV73/qx+r5Z8IOmLxJxqCXIsJGnum
H9XrRxuK0G+dkV6UoIMGHffZLoobdsB2c0YH++TzpvAOVjqiYOzr9Gx83DNBXCj8zeg+u7HrLrPI
ihG6V+RUQ1szT/1GvNA6XIrhblWTgQSx9baOUJXhbzdAqpFxwAohTHDar8egdU9tsROusuYTpFFn
/55aWQZaX6a3HjYc6A6ZfQFF1NGj28fvJ4GjAgMBAAGjggF3MIIBczAfBgNVHSMEGDAWgBStvZh6
NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUHmkqtNwo/kcYTiELP7ysES/wmPUwDgYDVR0PAQH/
BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwNgYDVR0lBC8wLQYIKwYBBQUHAwQGCisGAQQBgjcK
AwQGCisGAQQBgjcKAwwGCSsGAQQBgjcVBTAXBgNVHSAEEDAOMAwGCiqGSIb4TQEFAWkwSQYDVR0f
BEIwQDA+oDygOoY4aHR0cDovL2NybC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5h
bENBUm9vdC5jcmwwOgYIKwYBBQUHAQEELjAsMCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz
dC1wcm92aWRlci5jb20wNQYDVR0eBC4wLKAqMAuBCWludGVsLmNvbTAboBkGCisGAQQBgjcUAgOg
CwwJaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQApws2j/ZKjUmeiLwbtblDoVI+rV+bIpbex
IN/Vqa/IeSMSB3bmfswpEcYSZHHGjOI8qlyZt9dhT4nSDnrScKjmA8XvxZ3tmbNyYJybVQUV8jF/
DpADX1tGlMLxswxpJISXzLf0+DBr4cQ2ag9mwzrcN1nrOIOc+pxJtx9izyp3+bl3baulerkgZVS1
fotftH+FJLD/ex8BOcEuCIm2KVXJjs4YaZgoIBLYjTiK29JLVa15xdO305kPI1uXsu05sGuAwuFm
Sklb6k5H1/eHlUbZLm4qQDtOH00L0ShJx3BAIAjD5RYptJDQiyPZQUvt8cq+apYpVMv3yxHO8jex
40LgMIIGZjCCBU6gAwIBAgIKFyvckgACAAAU0jANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJV
UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSA0QTAeFw0x
MzA3MTgwMTEwMzdaFw0xNjA3MDIwMTEwMzdaMDsxFDASBgNVBAMTC0NoZW4sIFdlaSBEMSMwIQYJ
KoZIhvcNAQkBFhR3ZWkuZC5jaGVuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAN50qdmWdvh7vbj60QYyg7t3euDjJ8OU7EkwSPOgX3DKIW1PgAjzkpXvCxMhIBPr/KWX
7OVqYgP/vY8X0gLYrtGgBjwIkPOmFrSB2oRNEQiAtbP8YyOlprYHDeAUHFziVb6UPjPD9sR15q00
rH41v9qhRcll5V2cz4krCAdzSEWMGxnpZMBS8vV3zrwD1fiU0LLyn8Nb1u1MT0Sh0ZKQrWC/Icv1
UWklTdaGkbUxUa3eUZZdH5ayXIfLir4h3hChmkWsjLeLWXMHz/fCn3KW6qP64+WJJr0kcnpOM/Sp
07F9F6yfdg27HVWEHAphROkHJFdHK47RxnWWrnmB6lLMdzkCAwEAAaOCAywwggMoMEQGCSqGSIb3
DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG
9w0DBzAdBgNVHQ4EFgQUUIOKK8gtAh2SucBYccty6S33jggwCwYDVR0PBAQDAgeAMB8GA1UdIwQY
MBaAFB5pKrTcKP5HGE4hCz+8rBEv8Jj1MIHJBgNVHR8EgcEwgb4wgbuggbiggbWGVGh0dHA6Ly93
d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz
c3VpbmclMjBDQSUyMDRBLmNybIZdaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np
dG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwNEEuY3Js
MIH1BggrBgEFBQcBAQSB6DCB5TBsBggrBgEFBQcwAoZgaHR0cDovL3d3dy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwNEEoMikuY3J0MHUGCCsGAQUFBzAChmlodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNv
bS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1
aW5nJTIwQ0ElMjA0QSgyKS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhsOMdYSZ5VGD
/YEohY6fU4KRwAlngd69OZXwQwIBZAIBCDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoD
DDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwRQYDVR0RBD4wPKAk
BgorBgEEAYI3FAIDoBYMFHdlaS5kLmNoZW5AaW50ZWwuY29tgRR3ZWkuZC5jaGVuQGludGVsLmNv
bTANBgkqhkiG9w0BAQUFAAOCAQEAFKXJisQoKmP6JRz7poS0Z+AbM5QEpy/NTxT4lI+nHfznQcEW
emgt5pFJORthxKKFipifuHQxDYpnmNBq5wkn5zLpnMJQVMqoG/FPP2NWXW7NHRmzewousUCjm6ci
MSJbu7YNSfJAPz/fUznOKxmwBi5i+yROQXpeAx5eU9bcqaClBUt7e0FRyUCUEGfuwrzqamuPaxGc
Jg0zS7t7uPLtMQ+Xg83nVUBmWzjCXEzJesEG4KkY9lXInQojn7nIqSYJyQnm+0xK1TKNQ/G/J2DD
m2V7WDlfyECVbQwzwseJcFCET+zKvePggmgwoJ7Vjc/6gju3mj9wrr4TEil7PzVKIjCCBmcwggVP
oAMCAQICChcsF54AAgAAFNMwDQYJKoZIhvcNAQEFBQAweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT
AkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzAp
BgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwHhcNMTMwNzE4MDExMDUy
WhcNMTYwNzAyMDExMDUyWjA7MRQwEgYDVQQDEwtDaGVuLCBXZWkgRDEjMCEGCSqGSIb3DQEJARYU
d2VpLmQuY2hlbkBpbnRlbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpHWFM
hzvKyQ+h07xAyVymceQlT/Y1YK+nxXKFLq6Kglz8suv/Uk4ur+YXoBfW/+OWxjYU+misOO+apdAw
my3KXs+222bBd7hmxvMdOuz5jN1m+dLYlMlWpWyvLe+3531ufG4yymmlGxfifVtqKVmWSZ8li1gm
MbOGip1GU1dXfdckGwinmRFaSHFThcy+6jOKMY88cf7gRY/pJP6g3/tSwnO3LZgRZzqBu7VkZJpE
phgfPHMgmNLWQRUuQ/PEO/XrLkCrNWo90RhQzYbvWMFOx+/y/VGRvf/QKqJBUj+cDOT7qLtp15lm
vm5oBGC/qBLv5ty2ZSHU/lUih1Io4nclAgMBAAGjggMtMIIDKTBEBgkqhkiG9w0BCQ8ENzA1MA4G
CCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0O
BBYEFIQlFPFOAdRJpFVdkBxzADk9BtROMAsGA1UdDwQEAwIEMDAfBgNVHSMEGDAWgBQeaSq03Cj+
RxhOIQs/vKwRL/CY9TCByQYDVR0fBIHBMIG+MIG7oIG4oIG1hlRodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjA0QS5jcmyGXWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDRBLmNybDCB9QYIKwYBBQUH
AQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2Vy
dGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDRBKDIp
LmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9y
eS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIw
NEEoMikuY3J0MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgENMB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBFBgNVHREEPjA8oCQGCisGAQQBgjcU
AgOgFgwUd2VpLmQuY2hlbkBpbnRlbC5jb22BFHdlaS5kLmNoZW5AaW50ZWwuY29tMA0GCSqGSIb3
DQEBBQUAA4IBAQBKK79ulOFE5/S7yfejfIXz8xX3aRUmggULkjwh4sTe1M6JEKLDB9AqzNMKb/hy
PHPDFAlSuYToRu5QUiIIREdC4+RJhZrJ/NRELZktPJrOIpydhKsOAODNle2Rlypq9XvmeCqElLiR
XZTrBQQ4j4bMhnJVjS2h0ZULsR3qraV3ssWYjC1d6mBysmf4IdVnNSKECjGAJhLhwsow9igtjCzz
qKZ9A62vrG+ag/vnlx8bOO7ReqoK/X3hCYvuappzZ7udulpjf5zD/oAv5xJU0S0mSr1XKyfNOCIT
btX0zJM9tOoV1zr0eJb1I+aulgCjqqxaZqbvWdkQPdn++dAgQsmAMYIDvDCCA7gCAQEwgYcweTEL
MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMR
SW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vpbmcg
Q0EgNEECChcr3JIAAgAAFNIwCQYFKw4DAhoFAKCCAgkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTMwODAyMDYzMzU5WjAjBgkqhkiG9w0BCQQxFgQUU0szBQqrHyk3
00cWkuAJkNAF1rQwcgYJKoZIhvcNAQkPMWUwYzALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoG
CCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAIC
MAsGCWCGSAFlAwQCATCBmAYJKwYBBAGCNxAEMYGKMIGHMHkxCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSsw
KQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDRBAgoXLBeeAAIAABTTMIGa
BgsqhkiG9w0BCRACCzGBiqCBhzB5MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFDASBgNVBAcT
C1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwg
RXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSA0QQIKFywXngACAAAU0zANBgkqhkiG9w0BAQEFAASC
AQBHOVJ8v26UwJh9yvZ9FQUcPFtV8uJx2HBXOaqoHDKtS3KWAOjFvfJxMdv/+gyLCvzjPUbp90DN
1GACK/Qye17dtXaxYxjkTZi2UwzoW9lYBqVvbYLY36gh6evmEQ9sKjHCFa1jKG/bi3bwibm+lgx3
KgeDmVRQCBsQQ8L8S9xR8QtBOGl0QLbdH9RKTEbIeKtt1DCaS93R9dNGj7mEQr+QtYZisxdjjBP7
+w4hCSQ5HfbgEouelZ7LvGGaSMWYROs9WDmlS8le5TK/v6gdfxL3W5Wtn8B+OZd4fntBR6OqzBLU
7ievh5r1t0WzgO5pbrUSFzPDTmcobVbgUCWcERfXAAAAAAAA
------=_NextPart_000_0063_01CE8F8D.53576440--
10 years, 4 months
[Engine-devel] Java Newbie: Renaming some functions to fix findbugs warnings
by Adam Litke
Hello,
I am working on resolving some warnings produced by findbugs and am looking for some advice on how to properly resolve the problem.
The Frontend class has several pairs of methods where a capitalized version is a deprecated static form and the camelCase version is the instance method.
For example:
@Deprecated
public static void RunQuery(...)
- and -
public void runQuery(...)
In both cases the parameters are the same so simply renaming RunQuery to runQuery will result in a conflict. Since I am new to Java and the ovirt-engine project I am looking for some advice on how to fix the function name without breaking the code or people's sense of aesthetics. Since this is a deprecated function, would it be terrible to rename it to 'runQueryStatic' or 'runQueryDeprecated'? Since the language provides syntactic annotations for 'static' and 'deprecated', both of these names feel dirty but I am not sure what would be better. Thanks for helping out a newbie!
--Adam
10 years, 5 months
[Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
by Martin Perina
Hi Mike,
----- Original Message -----
> From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> To: "engine-devel" <engine-devel(a)ovirt.org>
> Cc: "Barak Azulay" <bazulay(a)redhat.com>, "Martin Perina" <mperina(a)redhat.com>, "Livnat Peer" <lpeer(a)redhat.com>,
> "Itamar Heim" <iheim(a)redhat.com>
> Sent: Monday, November 11, 2013 8:49:33 AM
> Subject: Custom properties per device + vNIC profile = not working (< 3.3)
>
> Hi,
>
> I came across a situation where I wanted to define custom properties on a
> vNIC profile sitting under a network in a 3.2 data center.
> From what I saw the configuration value for custom properties
> (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1,
> 3.2, 3.3).
> Since vNIC profile is located under the DC tree, it takes the DC version -
> 3.2 in this specific case.
Custom Device Properties were designed to be specified for each cluster version
independently, it doesn't care about DC version. AFAIK cluster version defines
what features are available ...
>
> I tried to set the config value for 3.2 but got:
> $ engine-config -s
> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}"
> --cver=3.2
> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key
> CustomDeviceProperties. Device custom properties are not supported in
> version 3.2
>
> This is already not very good, since in a 3.2 DC there can be 3.3 clusters
> with 3.3 hosts that do support custom device properties.
Specify your properties for 3.3 version, since they will be used in 3.3 clusters ...
>
> I also tried to alter the config value in the DB directly, but the custom
> properties code ignored it since custom properties are not supported in 3.2.
> So, de facto, I have no reasonable way as a user to define custom device
> properties to use for my vNIC profiles in DC < 3.3.
There are two configuration properties for Custom Device Properties:
1) SupportCustomDeviceProperties
- defines in what version properties are supported
- cannot be altered by users of course
2) CustomDeviceProperties
- holds properties specification for each version
- can be defined using engine-config
>
> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for
> this, however I also want to discuss the situation:
I looked at the bug and the problem is, that management network profile
is bound to DC and not the Cluster. And that's something we never thought of ...
>
> 1. As a user, I can't set custom properties for level < 3.3 which is not
> good.
Well, it's 3.3 feature, so it looks OK for me
> Removing the blocking, and loading custom properties for all versions would
> fix the bug and allow using custom device properties for older versions, the
> reasonable place to block this would be running a VM (or plugging a device).
> Basically this is the lesser issue..
>
> 2. I just don't see the added value of splitting the definition of the
> properties per level..
The idea behind the version splitting was:
1) We have a device with a feature that doesn't work correctly with version 3.3,
but it's fixed in 3.4
2) By specifying custom property per version we cane disable this feature for 3.3
and enable for 3.4
> The custom properties are extensions which might or might not be available to
> a certain VM, I don't see how having different sets of custom properties per
> version (what version, DC version, cluster version?) would make any
> difference - either the VM can utilize the extension given some state of the
> system, or it can't, but the determining factor is not the version but
> rather the availability of the extension.
> For example, I can have a hook for vNIC altering some property installed on
> host A and not host B, if the VM runs on host A it will get this capability
> and on host B it won't, regardless the DC version the VM is in.
>
> This is not to say we shouldn't block custom properties on the engine-VDSM
> API level since it's only available since 3.3, but this is handled by
> another config value (SupportCustomDeviceProperties) which is not alterable
> by the user.
> So basically, I think splitting the value per version is over complication
> and see no added value to the users, just more maintenance should they
> choose to use this feature.
>
> Your thoughts please.
AFAIK only network and storage team wanted to use device custom properties
in 3.3 version, but I'm not sure what's current usage status.
But IMHO it's too late for 3.3 to change specification ...
Martin
10 years, 5 months
[Engine-devel] Problem building 3.3.1 branch
by Bob Doolittle
Hi,
I'm trying to build engine for the first time and running into a build
error. I'm a seasoned Unix developer, but new to some aspects of Linux
development like git and maven, so I could be doing something naive.
I'm following the instructions here:
http://www.ovirt.org/OVirt_Engine_Development_Environment
I did a clone of the engine repository, and did "git checkout -b
myengine origin/ovirt-engine-3.3.1" to create my own branch based on
3.3.1 (current - I realize it's not quite done).
Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it failed
when building the "Engine Web Root", specifically in the
FileServletTest. Relevant build log is here: http://pastebin.com/JRcyWvtr
Can anyone suggest what I've done wrong, or whether there's a problem
with the repository at the moment?
I'd appreciate any guidance.
Thanks,
Bob
10 years, 5 months
[Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
by Shubhendu Tripathi
This is a multi-part message in MIME format.
--------------020507040501040703080208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
// return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
// ? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!
But while translation of the error messages, all the occurrences of "."
get replaced with "_".
This causes an issue for the gluster errors. If the error message sent
from gluster has "."s (say IP Address of a host or FQDN for a host),
that also gets replaced with "_" and the error message does not look
correct.
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of "." with "_", if the flag is set it will not do the
replacements.
Regards,
Shubhendu
--------------020507040501040703080208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
In the case of Gluster, as there are no one to one mappings
available for all the error messages from Gluster, we set the error
in the VdcFault object as NULL.<br>
We also populate the actual error from the Gluster as error message
in the fault object.<br>
<br>
<font color="#000099"><i>getReturnValue().getExecuteFailedMessages().add(error);</i><i><br>
</i><i>getReturnValue().getFault().setMessage(error);</i><i><br>
</i><i>getReturnValue().getFault().setError(null);</i></font><br>
<br>
Because of above settings and the below code snippet in <i>Frontend.java</i>
class the error message as is gets displayed on the error dialog -<br>
<font color="#000099"><i><br>
</i><i>public String translateVdcFault(final VdcFault fault) {</i><i><br>
</i><i> return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError()
== null</i><i><br>
</i><i> ? fault.getMessage() :
fault.getError().toString());</i><i><br>
</i><i>}</i><i><br>
</i></font><br>
Well and good till now !!<br>
<br>
But while translation of the error messages, all the occurrences of
"." get replaced with "_".<br>
This causes an issue for the gluster errors. If the error message
sent from gluster has "."s (say IP Address of a host or FQDN for a
host), that also gets replaced with "_" and the error message does
not look correct.<br>
<br>
Request your suggestion for handling such a case.<br>
<br>
<b>PS: </b>One thing I can think of is, introducing a flag called <i>isExternalError</i>
in <i>VdcFault</i> class to identify if the source of the fault is
external. From Gluster we would set the flag as <i>true</i>, and
while replacement of "." with "_", if the flag is set it will not do
the replacements.<br>
<br>
Regards,<br>
Shubhendu <br>
</body>
</html>
--------------020507040501040703080208--
10 years, 5 months
