oVirt UI log records persisted in browser's local storage
by Vojtech Szocs
Hi,
with patches [1,2] merged recently into master branch, oVirt UI
(WebAdmin and UserPortal) now persists client-side log records
in browser's local storage [3] in addition to logging them via
console.log API [4]. This means that client-side logs are kept
in browser's storage between browser restarts, unless the user
manually clears the storage.
To inspect "localStorage" object in Firefox:
* Menu / Developer / Toggle Tools
* on Console tab, type "inspect(localStorage)"
Client-side logs now use application-specific key prefix, e.g.
"ENGINE_WebAdmin_MyKey" or "ENGINE_UserPortal_MyKey" to avoid
clashes. For backwards compatibility (any existing items with
un-prefixed keys), UI has a fallback to read the un-prefixed
key when the prefixed one is missing. (Newly persisted items
always use the key prefix.)
In addition to changes above, any uncaught errors that originate
from UI code are now properly caught and logged. This means that
you shouldn't see uncaught JavaScript errors in browser's error
console anymore.
Regards,
Vojtech
[1] https://gerrit.ovirt.org/#/c/25444/
[2] https://gerrit.ovirt.org/#/c/41404/
[3] http://www.w3.org/TR/webstorage/#the-localstorage-attribute
[4] https://developer.mozilla.org/en-US/docs/Web/API/Console/log
10 years
CI flag enabled to all projects
by David Caro
--47eKBCiAZYFK5l32
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi everyone, to ease our current issues, the CI flag has been enabled to all
the projects. It will be the only flag that jenkins will set/unset and it c=
an
also be set by a maintainer. A +1 is required to enable the submit but a -1
will not block (so if jenkins -1 it and a maintainer +1 the +1 prevails).
The permissions to the maintainers is added manually, that means that I mig=
ht
have messed some of them, if you have any issues ping me and I'll check.
Any project that does not have any jenkins jobs, will have to get it set
manually by a maintainer (or create a jenkins job, that would be best...).
Thanks!!
--=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
--47eKBCiAZYFK5l32
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVgRszAAoJEEBxx+HSYmnDiQEIAIB+mB1/JWgaSpEyOnqwumQ/
oKKNUgtGK43dt29dxMSoXT5Z1nUxrvnwDNbx9fDqTY4/x/E2vNvIkR7CrxdI+B/R
OGA01EB8x2ZxDxUNiZtRMvTwfwh2IFCgFd1tOujPGgcOxJRUgywWQVaiIuH5SfHv
no7WyuEZjzF5JhBHEOUfGGbF/kS4YoDB93rDrwABLQMbk1sKnSe6M2DTpl3hTyBO
or+Vbw1n2PmOk+YNQcsJVZr7msz1H4Cmwi1+4M9XdElR3Vj7tTuML7/PMlymiT7F
FpetYzm1sHeKBNjtn3iqmfVbgV2DaK+LOH6XbL9B2DBK6g3vq0mqkh9Nt9SiSAI=
=Onxt
-----END PGP SIGNATURE-----
--47eKBCiAZYFK5l32--
10 years
Postponing 3.6.0 second alpha to next week
by Sandro Bonazzola
Hi,
due to instability of the current code, we need to postpone second alpha to next week.
Maintainers:
- please ensure that all packages you maintain builds in jenkins
- please ensure that all the dependencies required by your packages are available either in ovirt repository or in an external repository included in
ovirt-release repo files.
- please ensure that engine is at least able to add a couple of hosts, create a vm on one host and migrate it to the other one.
Infra:
- please help keeping jenkins monitored and stabilizing it.
Community:
- please help testing nightly build while stabilizing it for the second alpha release.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
Libvirt secrets management - take 2
by Nir Soffer
Hi all,
Recently support for Ceph network disk landed in master. It its possible
now to start a vm using Ceph network disk or hot-plug/unplug such disk
using Cephx authentication.
However, to make it work, you must add the relevant Ceph secret to
libvirt manually, in the same way it is done in OpenStack deployment.
Our goal is to manage secrets automatically and use ephemeral (safer)
secrets.
The next patches in the Ceph topic [1], implement secret management in
the same way we manage storage domains or server connections:
The concept is - all hosts can use all secrets, so you can migrate a vm
using Ceph disk to any host in the cluster.
1. When host becomes up, we register the secrets associated with all the
current active domains with libvirt
2. When activating a domain, we register the secrets associated with the
new domain with libvirt
3. When deactivating a domain, we unregister the secrets associated with
the domain from libvirt
4. When moving host to maintenance, we clear all secrets
5. When vdsm shutdown or starts, clear all secrets to ensure that we don't keep
stale or unneeded secrets on a host
This system seems to work, but Federico pointed few issues and suggested
a new (simpler?) approach.
In future libvirt version, libvirt will support the concept of transient
secrets so you can start a transient vm using secret without registering
the secret with libvirt before starting the vm. The secret will be
specified in the vm XML (for starting a vm) or disk XML (for hot-plug).
This will make our secret management system and APIs useless.
Managing state on multiple hosts is hard; we will probably have to deal
with nasty edge cases (e.g. lost messages, network errors), which may
lead to host with missing secret, which cannot run some vms. We probably
do this right for storage domains (after 8 years?), and we should not
assume that we are smarter and secret management will work in the first
try.
The new approach is to *not* manage state or multiple hosts. Instead,
send the required secrets only to the host that starting a vm or
hot-plugging a disk that need a libvirt secret:
1. When starting a vm, add the required secrets to the vm description.
On the host, vdsm will register these secrets with libvirt before
starting the vm.
2. When migrating a vm, add the required secrets to the vm description.
On the host, vdsm will send these secrets to the destination host,
and on the destination host, vdsm will register the secrets with libvirt
before starting the vm.
3. When hot-plugging a disk, send the secret if needed in the disk
description. On the host, vdsm will register the secrets with libvirt.
4. When vdsm shutdown or starts, clear all secrets to ensure that we don't keep
stale or unneeded secrets on a host
5. We never unregister secrets, since they are ephemeral anyway.
6. Alternatively, we can implement secrets reference counting so when a vm
stops or disk is hot-unplugged we decrease the reference count on the
secrets associated with this vm/disk, and if no other vms need the
secret, we can unregister the secret from libvirt.
The new approach is simpler, if we avoid the fancy secret reference
counting. I believe we can get it merged in couple of weeks with help
from the virt team.
Please share your thoughts on these alternative solutions.
Thanks,
Nir
[1] https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic...
10 years
master broken
by Piotr Kliczewski
Guys,
I attempted to add a host using latest master code and got following exception:
2015-06-16 10:01:28,854 WARN
[org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand]
(http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action
'AddVds' failed for user admin@internal. Reasons:
VAR__ACTION__ADD,VAR__TYPE__HOST,$server
192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store
fingerprint to db for host 192.168.1.7:
javax.persistence.PersistenceException:
org.hibernate.id.IdentifierGenerationException: ids for this class
must be manually assigned before calling save():
org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER
2015-06-16 10:01:41,724 ERROR
[org.ovirt.engine.core.utils.transaction.TransactionalInterceptor]
(http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a
new transaction: javax.persistence.PersistenceException:
org.hibernate.id.IdentifierGenerationException: ids for this class
must be manually assigned before calling save():
org.ovirt.engine.core.common.businessentities.VdsStatic
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548)
[jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60)
[dal.jar:]
at org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java)
Thanks,
Piotr
10 years
vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged have been disabled
by Sandro Bonazzola
Hi,
I disabled vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged since they get stuck testing jsonrpc and cause jenkins job to grow over
500 jobs taking busy for days the slaves.
Please either fix vdsm or the unit tests before enabling these jobs again.
Thanks.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
Repository closure is currently failing for 3.5
by Sandro Bonazzola
Hi,
repository closure is currently failing for 3.5 on:
01:18:15 package: ovirt-optimizer-jboss-0.9-1.el6.noarch from check-custom-el6
01:18:15 unresolved deps:
01:18:15 ovirt-engine-wildfly >= 0:8.2
Since Wildfly support is targeted to 3.6 please provide a 3.5 branch for ovirt-optimizer or give ack for removing ovirt-optimizer from published rpms.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
VDSM from 3.5 branch is currently failing on Fedora 20
by Sandro Bonazzola
VDSM from 3.5 branch is currently failing on Fedora 20:
make[1]: Entering directory `/builddir/build/BUILD/vdsm-4.16.20'
make check-local
make[2]: Entering directory `/builddir/build/BUILD/vdsm-4.16.20'
python -c 'import pyflakes; print("pyflakes-%s" % pyflakes.__version__)'
pyflakes-0.7.3
find . -path './.git' -prune -type f -o \
-name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes | \
grep -w -v "\./vdsm/storage/lvm\.py.*: list comprehension redefines 'lv' from line .*" | \
while read LINE; do echo "$LINE"; false; done
./tests/functional/networkTests.py:80: redefinition of unused 'vdsm' from line 43
./tests/functional/networkTests.py:88: redefinition of unused 'vdsm' from line 43
make[2]: Leaving directory `/builddir/build/BUILD/vdsm-4.16.20'
make[2]: *** [check-local] Error 1
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/vdsm-4.16.20'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.fmuLh5 (%check)
Please fix it.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
Automated builds and releases
by David Caro
--kkRamCq5m5VQq0L6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi everyone!
In an effort to improve the project workflow and ease the maintenance and
improve the quality of the project releases I want to propose start working
towards automated builds and releases, the main ideas are the following:
* Stop building differently for release and non-release:
- Building only once, testing what you build and release what you test
- Don't use two different version strings, one for testing and one for
release
* Automate the build process, and the release process, directly getting the
code from the repos (no manual build tarballs)
* Adopt semantic versioning, it's a lot more meaningful than the current sc=
heme
and fits very well with the above points
This will ease and lower the maintenance and the extra work required by
maintainers, release engineers (sandro) and infra itself by making releases=
as
easy as hitting a button at any time. That will allow us to lower the time
features and fixes get to the users, and deliver packages and builds that h=
ave
passed through all the tests we have, instead of rebuilding on another env,=
at
another time, by someone else, and passing only manual testing.
wdyt?
--=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
--kkRamCq5m5VQq0L6
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVcZDBAAoJEEBxx+HSYmnDT08IAJcqZK4lgNV1DqOTvfXrB7Tl
7f7ceRfBezUVVnwQigvDuUz7LqT9SPO9jaNonFzHHuEiBanaug7W+YUdsFPyIEXF
khJriJRocs2brZKFlL4IGfHC1yQGh6FomILAJkIUBWyzo+YJWhtobkfz1346q2dl
8B8k7ReZxTCnrB3Rb+dU0i4XY75IGKX0GFMOHQx9Ws0cFbhQBrqd7vW8svTmuFcY
6mtdzvQBmARqYM/wwkC9lLVUAZ0zlfsEoPAU2JSaSCXNEQkd0cy5XLua1oofUVuv
t4epBTRu4RXTwblGwcCqrxC5XUoSerHWM2O7Yv5yaXYa6LP4OXSOy4cvEfju+Zk=
=8dph
-----END PGP SIGNATURE-----
--kkRamCq5m5VQq0L6--
10 years
[ANN] oVirt 3.5.3 Second Release Candidate is now available for testing
by Sandro Bonazzola
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The oVirt team is pleased to announce that the 3.5.3 Second Release Candidate is now
available for testing as of May 28th 2015.
The release candidate is available now for Fedora 20,
Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and
Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar).
This release of oVirt includes numerous bug fixes and one CVE fix for the VENOM Vulnerability.
See the release notes [1] for a list of the new features and bugs fixed.
Please refer to release notes [1] for Installation / Upgrade instructions.
A new oVirt Live ISO is already available as well[2].
Please note that mirrors[3] may need usually one day before being synchronized.
Please refer to the release notes for known issues in this release.
[1] http://www.ovirt.org/OVirt_3.5.3_Release_Notes
[2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/
[3] http://www.ovirt.org/Repository_mirrors#Current_mirrors
- --
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVZrrzAAoJEHw3u57E4QAOnX4QAMFi+d4Vq5jnZ0e+LaD1vB9R
GmT+k21q6vybjIvovPh7q6StCtPS0sg15BoH5JTmTfl5IWL01qMsFvw/G32PIjZI
u3mm2Z3evbxPg9qsqJPyJm/jAlRHv/L6ntLJaJBDPDSO6Y0iqiHTVUQG16easW3L
ZnUC2IM5TpHuU3PcgVp8zY9gqFqQWnnsA8deJXBvif9J8RdSf7DnkFha9/Ei3v0E
1btkzt0XVS3Cate8pEaTT8zSoE/tOBBS/D65HsnnZdD13RAxYkolzuPvT+7BlmUO
QMhyIE7msWex048HrcDVTEDLrkYF2SpAmYix3sA2O9+AIujenpICHJ8JyxAc+BmJ
scsvv99iDLU3wkpMwKiIABj7nE8gIiUbyZBNaxsxQJ0jurLZGHGIhQGLAJ2q/rd7
MTkcDXOBOZHEadqs87mSEzHt1pQCmZ40KSJCvyWbqa7vFv6kyOgOs3PldoizsOyV
Z1DlDmfMM8hs/6LOP/Mr/4p/l3JgS3gbOy34L2q9J/B+BX/XU7H2bOk6GTEMVPOn
av7m2kDs8DlQJzSqZAURZNt6XTnGGw05THOBWD8NmHuvlVZsSF1mxKb0BC+LpRcs
QmLGAtT12Y2Wnq1xwzcRav9+wiIeEYTVJCbyohMLyqTHqPgRstpeF3JulpqILo5I
rHhGapreYDlzy06Ki7X7
=pUqF
-----END PGP SIGNATURE-----
10 years