[INFO] ------------------------------------------------------------------------
[INFO] Building builtin-extensions 3.5.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ builtin ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 4 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ builtin ---
[INFO] Compiling 167 source files to /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/target/classes
[INFO] -------------------------------------------------------------
[WARNING] COMPILATION WARNING :
[INFO] -------------------------------------------------------------
[WARNING]
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[19,24]
LdapCtxFactory is internal proprietary API and may be removed in a future release
[WARNING]
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[19,24]
LdapCtxFactory is internal proprietary API and may be removed in a future release
[WARNING]
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[19,24]
LdapCtxFactory is internal proprietary API and may be removed in a future release
[WARNING] class file for org.springframework.beans.factory.InitializingBean not found
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[68,40]
LdapCtxFactory is internal proprietary API and may be removed in a future release
[INFO] 4 warnings
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[64,26]
error: cannot access InitializingBean
[ERROR]
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[145,31]
error: cannot access DisposableBean
....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:34 min
[INFO] Finished at: 2014-11-07T16:05:23+01:00
[INFO] Final Memory: 174M/873M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project builtin: Compilation failure:
Compilation failure:
[ERROR]
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[64,26]
error: cannot access InitializingBean
[ERROR]
/root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[145,31]
error: cannot access DisposableBean
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
Hi all,
as you may know, a subpart of the instance type entity (the "marked" column from [1]) are the ones which are marked with the chain icon in the VM dialogs.
The meaning is that this fields are so important that if you want the newly created VM to be based on that instance type, you can not change any of this fields.
The problem was that too many of the fields was "marked" which would force the user to create lots of instance types like: "big with soundcard", "big with smardcard and
soundcard", "medium with smardcard and without soundcard" etc. This after some more thinking seems to be an incorrect approach - the list of "marked" fields should be small and contain
only the really most important fields which lets you to categorize the VMs and not all the devices.
I have proposed two patches ([2], [3]) which implement this. According to this patches only the following fields will be "marked":
- memory size
- num of sockets/cores per socket
- HA
- migration model/downtime
- priority
- balloon
- min allocated memory
So the behavior will now be:
- the instance type still contains all kinds of devices we support
- only a small part of them are "marked"
- when the user creates a VM from an instance type, he will be provided by a big set of defaults from the instance type he can tune
- he will also be provided by a small set of fields he can not change if does not want to be detached from the instance type
Thoughts?
Tomas
[1]: http://www.ovirt.org/Features/Instance_Types#Design
[2]: http://gerrit.ovirt.org/#/c/34915/
[3]: http://gerrit.ovirt.org/#/c/34916/
Hi,
I am working on a major front-end re-factor patch [1], and I have a question
about some of the re-factoring I did in the ImportVmFromExportDomainModel. I
have the question in a TODO here [2]. But basically I would like someone
familiar with that particular piece of code to take a second look at that part
of my patch and let me know if I probably broke it or not.
The gist of the patch is that instead of using a custom class resolver, now
all ListModels will be managed by our dependency injection framework GIN.
Thanks,
Alexander
[1] http://gerrit.ovirt.org/#/c/34193
[2]
http://gerrit.ovirt.org/#/c/34193/16/frontend/webadmin/modules/uicommonweb/…
Hi,
currently ksmd is a single process
and is thus bound to one core.
This leads to some scaling problems such as:
If you got a lot of vms on one host with huge amounts
of ram you can observe that the cpu usage by ksmd
goes easily to 100%.
I wonder if ksmd could not be split up
in child/worker threads, thus enabling higher density
of vms on one host.
or can this just be tweaked by altering values in
/etc/ksmtuned.conf ?
What do you think?
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
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
Hi,
I would like to propose Roy Golan as VDSM Fake (http://www.ovirt.org/VDSM_Fake) co-maintainer.
Your response would be appreciated.
Thanks in advance.
Tomas
Hi,
Currently we are unable to send long values between engine and vdsm
due to xmlrpc limitation. There is an extension i8 for xmlrpc which
enables 64bit numerical values (long) but we can't use it due to
compatibility reasons. To workaround this limitation people cast long
to string before sending it to the other side. I came up with engine
and vdsm patches [1] to make this type conversion in single place.
Jsonrpc supports long marshalling so by having above patches we can
start to use long types without worrying about type conversion.
Please let me know what do you think about it and whether there are
any reasons why we should not have this changes in 3.6.
Thanks,
Piotr
[1] http://gerrit.ovirt.org/#/q/status:open+topic:long-type-for-xmlrpc,n,z
Hi,
Release criteria discussion started on 2014-10-22 and should end on 2014-11-12 as per current release process [1].
Current options are:
1) keeping the same release criteria we had for 3.5 [2]
2) review the proposed changes [3] and prepare new release criteria for 3.6
Release management for 3.6.0 has been created [4]
The key milestones for this release must be scheduled:
Key Milestones
Release criteria discussion start: 2014-10-22
Release criteria ready: 2014-11-12
Feature freeze: 60 Days before release
First Test Day: 45 days before release
Release Candidate: 30 days before release
Release: 6 months after oVirt 3.5.0 release
Two different proposals have been meed about above scheduling [5]:
1) extend the cycle to 10 months for allowing to include a large feature set
2) reduce the cycle to less than 6 months and split features over 3.6 and 3.7
A tracker bug for 3.6.0 has been created [6] and currently shows no blockers.
There are 395 bugs [7] targeted to 3.6.0.
Excluding node and documentation bugs we have 375 bugs [8] targeted to 3.6.0.
[1] http://www.ovirt.org/Release_process
[2] http://www.ovirt.org/OVirt_3.5_release-management#Release_Criteria
[3] http://lists.ovirt.org/pipermail/devel/2014-September/008695.html
[4] http://www.ovirt.org/OVirt_3.6_Release_Management
[5] http://lists.ovirt.org/pipermail/users/2014-November/028875.html
[6] https://bugzilla.redhat.com/show_bug.cgi?id=1155425
[7] http://goo.gl/zwkF3r
[8] http://goo.gl/ZbUiMc
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
Hi,
We're going to start composing oVirt 3.5.1 RC on *2014-11-25 08:00 UTC* from 3.5 branch.
Maintainers:
- Please be sure that 3.5 snapshot allow to create VMs before *2014-11-24 15:00 UTC*
- Please be sure that no pending patches are going to block the release before *2014-11-24 15:00 UTC*
- If any patch must block the RC release please raise the issue as soon as possible.
A bug tracker [1] has been opened and shows 1 open blocker:
Bug ID Whiteboard Status Summary
1142710 integration NEW Volume creation failed while deploying Hosted Engine on iSCSI
There are still 181 bugs [2] targeted to 3.5.1.
Excluding node and documentation bugs we still have 151 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.
- 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.
- 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
Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-11-04-14.00.html
Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-11-04-14.00.txt
Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-11-04-14.00.log.html
=================================
#ovirt: oVirt Node Weekly Meeting
=================================
Meeting started by fabiand at 14:00:01 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-11-04-14.00.log.html
.
Meeting summary
---------------
* Agenda (fabiand, 14:00:08)
* oVirt 3.5 (fabiand, 14:00:15)
* Other Items (fabiand, 14:00:20)
* oVirt 3.5 (fabiand, 14:00:28)
* fabiand did not build Node for 3.5, on list for this week (fabiand,
14:05:10)
* Other Items (fabiand, 14:08:30)
* Work on supporting CentOS 6.6 is already on it's way (fabiand,
14:08:55)
* Work on supporting CentOS 7.0 is also on it's way (fabiand,
14:09:11)
* HE needs some more fixes on 3.5 (fabiand, 14:12:29)
Meeting ended at 14:15:55 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* fabiand (37)
* dougsland (6)
* rbarry (3)
* ovirtbot (2)
* osvoboda (1)
* bkp (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
