ovirt-engine housekeeping
by Sandro Bonazzola
Hi,
as we did for 3.5, I'm going to do some housekeeping on ovirt-engine git
repo.
Unless a good reason is given I'm going to drop the following branches on
Firday July 15th, being all of them still reachable by tags.
ovirt-engine-3.6.0 e55a3b57c7541a60383a8d55f02a6ddeb6ae2ea6
ovirt-engine-3.6.1 81deade7478d1f1b55fd5cbc80a3b3003d9d1a18
ovirt-engine-3.6.2 7db5d96e4ca9a0c4896f627ba4a8835fd395e0b1
ovirt-engine-3.6.3 cb35e8c0070fd666f6a59b2e51993daa94e8ce6a
ovirt-engine-3.6.4 e25f112ba2bac541b0e37d3cb60a1eda346b1ed9
ovirt-engine-3.6.5 cd869286db412bbc2d750838eef6f246b229aae2
ovirt-engine-3.6.6 d37fcd09f558d8884b804f8e774f9545b0981fc5
ovirt-engine-3.6.7 f94c8a7131ab2b23219916ee05030b499aec6252
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 5 months
oVirt metrics
by Yaniv Bronheim
Hi,
In oVirt-4.0 we introduced integration with metrics collectors, In [1] you
will find a guide for utilizing your environment to retrieve visualized
reports about hosts and vms statistics.
I encourage to try that out and send us requests for additional valuable
metrics that you think vdsm should publish.
This area is still work in progress and we plan to support more
technologies and different architectures for metrics collections as
describes in the post. This will follow by additional links in the post
([1]) that describe how to do so.. stay tuned.
[1] https://bronhaim.wordpress.com/2016/06/26/ovirt-metrics
<https://bronhaim.wordpress.com/2016/06/26/ovirt-metrics/>--
*Yaniv Bronhaim.*
8 years, 5 months
[ACTION REQUIRED] broken dependency with vdsm git6e84643
by Sandro Bonazzola
DEBUG util.py:417: Error: Package:
vdsm-4.18.999-232.git6e84643.el7.centos.x86_64 (ovirt-master-snapshot)
DEBUG util.py:417: Requires: safelease >= 1.0-7
DEBUG util.py:417: Available: safelease-1.0-5.el7.x86_64
(centos-epel)
DEBUG util.py:417: safelease = 1.0-5.el7
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 5 months
[ACTION REQUIRED] oVirt 4.0.1 RC2 build starting
by Sandro Bonazzola
Fyi oVirt products maintainers,
An oVirt build for an official release is going to start right now.
If you're a maintainer for any of the projects included in oVirt
distribution and you have changes in your package ready to be released
please:
- bump version and release to be GA ready
- tag your release within git (implies a GitHub Release to be automatically
created)
- build your packages within jenkins / koji / copr / whatever
- verify all bugs on MODIFIED have target release and target milestone set.
- add your builds to releng-tools/releases/ovirt-4.0.1_rc2.conf within
releng-tools project
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 5 months
Caching of data from the database done properly
by Roman Mohr
Hi Everyone,
I wanted to discuss a practice which seems to be pretty common in the
engine which I find very limiting, dangerous and for some things it
can even be a blocker.
There are several places in the engine where we are using maps as
cache in singletons to avoid reloading data from the database. Two
prominent ones are the QuotaManager[1] and the MacPoolPerCluster[2].
While it looks tempting to just use a map as cache, add some locks
around it and create an injectable singleton, this has some drawbacks:
1) We have an autoritative source for our data and it offers
transactions to take care of inconsistencies or parallel updates.
Doing all that in a service again duplicates this.
2) Caching on the service layer is definitely not a good idea. It can
introduce unwanted side effects when someone invokes the DAOs
directly.
3) The point is more about the question if a cache is really needed:
Do I just want that cache because I find it convenient to do a
#getMacPoolForCluster(Guid clusterId) in a loop instead of just
loading it once before the loop, or do my usage requirements really
force me to use a cache?
If you really need a cache, consider the following:
1) Do the caching on the DAO layer. This guarantees the best
consistency across the data.
2) Yes this means either locking in the DAOs or a transactional cache.
But before you complain, think about what in [1] and [2] is done. We
do exactly that there, so the complexity is already introduced anyway.
3) Since we are working with transactions, a custom cache should NEVER
cache writes (really just talking about our use case here). This makes
checks for existing IDs before adding an entity or similar checks
unnecessary, don't duplicate constraint checks like in [2].
4) There should always be a way to disable the cache (even if it is
just for testing).
5) If I can't convince you to move the cache to the DAO layer, still
add a way to disable the cache.
For as long as there is no general caching solution with something
like ehcache or infinispan, in my eyes such small things matter a lot
to keep a project maintainable.
That are some of the best practices I have seen around caching
database data. It would be great if we could agree on something like
that. Maybe there is already an agreement on something and I am just
not aware of it.
Looking forward to hear your feedback.
Roman
[1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules...
[2] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules...
8 years, 5 months
oVirt 4.0.1 rc2 merge / branch / tag / bugzilla reminder
by Sandro Bonazzola
All stable branch maintainers, please make sure to
- merge all relevant open bugs until Tuesday morning 11:00 AM TLV time.
For each package that need to be built (i.e oVirt product) please make sure
every bug in MODIFIED has the right Target Release and Target Milestone.
A Target release should state the version of the package you're building
and should include the same version you used for the tag you just used for
this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.1.1, tr: 4.0.1.1)
A list of bugs that require attention is here:
-
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4....
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 5 months
oVirt 4.0.1 RC2 build planned
by Sandro Bonazzola
Fyi oVirt developers,
An oVirt build is planned for this Tuesday 11:00 AM TLV time (10:00 AM
CEST).
Taking into consideration the time it takes for Jenkins to run a full CI
everything need to be backported by Monday 11PM.
Please make sure to mark as verified and CR +2 so it will be ready for
merging Tuesday morning.
A list of pending blockers is available here:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4....
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8 years, 5 months
python-paramiko availability
by Paul Dyer
Hi,
I am trying to install the ovirt-4.0 engine to a fresh install of RHEL 7.2.
There is a dependency for python-paramiko, but it appears that rpm was
removed from RHEL between 6 and 7...
The dependency appears when I install ovirt-engine:
Error: Package: ovirt-engine-setup-base-4.0.0.6-1.el7.centos.noarch
(ovirt-4.0)
Requires: python-paramiko
This doc notes the package removal:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
Does anyone know where to source this package?
Thanks,
Paul
--
Paul Dyer,
Mercury Consulting Group, RHCE
504-302-8750
8 years, 5 months
