Fwd: Lago v0.37 Release announcement
by Nadav Goldin
---------- Forwarded message ----------
From: Nadav Goldin <ngoldin(a)redhat.com>
Date: Sun, Apr 23, 2017 at 5:55 PM
Subject: Lago v0.37 Release announcement
To: lago-devel(a)ovirt.org
Hi all,
On behalf of the Lago team, I'm pleased to announce Lago v0.37 is available!
What's new
=========
General
------------
1. Allow running arbitrary 'virt-customize' commands on template
disks, prior to boot-up, for example:
disks:
- build:
- virt-customize:
ssh-inject: ""
mkdir: "/tmp/some_dir"
template_name: el7.3-base
type: template
name: root
dev: vda
format: qcow2
Will create the directory /tmp/some_dir in the template disk and
inject Lago's generated ssh-keys to the root user. For a full list of
available commands please consult virt-customize docs[1], under
'Customization options' section.
2. Allow skipping the 'bootstrap' stage(virt-sysprep) per VM, by
defining 'bootstrap: false' under the VM definition.
Libvirt
----------
1. Use 'host-passthrough' as the default CPU mode.
2. Allow customizing CPU definitions, with 'cpu_custom' and
'cpu_model' parameters, see [2] for more details.
3. Automatically add DHCP leases for none management networks.
4. Auto select management network if not defined.
5. Allow defining custom DNS records in management networks.
6. Restrict DNS configurations to management networks only.
7. Enforce one management network per VM.
ovirtlago
-------------
1. Export junit XML reports generated by nose with *.junit.xml suffix.
2. Add '--with-vms' option to 'lago ovirt start'.
3. Allow defining a custom CPU <-> Cluster level mapping file.
For the full commit-log, which also includes several bug-fixes, see [3].
Upgrading
========
To upgrade using yum or dnf, simply run:
yum/dnf update lago
Resources
========
Lago Docs: http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
OST Docs: http://ovirt-system-tests.readthedocs.io/en/latest/
As always, if you find any problems, please open an issue in the GitHub page[4].
Enjoy!
Nadav.
[1] http://libguestfs.org/virt-customize.1.html
[2] http://lago.readthedocs.io/en/latest/LagoInitFile.html#domains-section
[3] https://github.com/lago-project/lago/compare/0.36...0.37
[4] https://github.com/lago-project/lago/issues/
7 years, 7 months
oVirt services outage last Friday [ 21/04/17 ]
by Eyal Edri
FYI,
During last Friday the data center which oVirt services are hosted on had a
major outage which affected some of the oVirt services, like the CI, e-mail
and oVirt repositories.
All systems should be up by now, although, since one the services which
were affected was e-mail, it might be that your emails are still in the
queue waiting to be sent.
If you still experiencing any service downtime, please report to
infra-support(a)ovirt.org.
We are working with the IT team of the DC to get the full RCA will report
once we have more info.
Thanks for the understanding and sorry for the inconvenience,
oVirt infra team
--
Eyal edri
ASSOCIATE MANAGER
RHV DevOps
EMEA VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
7 years, 7 months
Tests failure when building the latest master
by Shmuel Melamud
Hi!
Just tried to build the latest Engine from master and got a lot of
test failures. All related to ThreadPoolUtil. For example:
onSuccessReturnValueOk(org.ovirt.engine.core.bll.pm.StartVdsCommandTest)
Time elapsed: 0 sec <<< ERROR!
java.lang.ExceptionInInitializerError
at org.ovirt.engine.core.bll.VdsCommand.runSleepOnReboot(VdsCommand.java:103)
at org.ovirt.engine.core.bll.VdsCommand.runSleepOnReboot(VdsCommand.java:99)
at org.ovirt.engine.core.bll.pm.StartVdsCommand.teardown(StartVdsCommand.java:131)
at org.ovirt.engine.core.bll.pm.FenceVdsBaseCommand.executeCommand(FenceVdsBaseCommand.java:118)
.....
Caused by: java.lang.NullPointerException
at org.ovirt.engine.core.common.config.Config.getValue(Config.java:22)
at org.ovirt.engine.core.common.config.Config.getValue(Config.java:18)
at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalThreadExecutor.<init>(ThreadPoolUtil.java:34)
at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil.<clinit>(ThreadPoolUtil.java:110)
at org.ovirt.engine.core.bll.VdsCommand.runSleepOnReboot(VdsCommand.java:103)
at org.ovirt.engine.core.bll.pm.StartVdsCommand$MockitoMock$1274036240.runSleepOnReboot$accessor$RBFb71Df(Unknown
Source)
....
Do you know what may cause this?
Shmuel
7 years, 7 months
Fwd: Announcing Bugzilla 5 Public Beta!
by Sandro Bonazzola
---------- Forwarded message ----------
From: Christine Freitas <cfreitas(a)redhat.com>
Date: Thu, Apr 20, 2017 at 12:45 AM
Subject: Announcing Bugzilla 5 Public Beta!
Hello All,
We are pleased to announce Red Hat's Bugzilla 5 beta [1]! We’re inviting
all of you to participate.
We encourage you to test your current scripts against this new version and
take part in the beta discussions on the Fedora development list [2].
Partners and customers may also use their existing communications channels
to share feedback or questions. We ask that you provide feedback or
questions by Wednesday, May 17th.
Here is a short list of some of the changes in Bugzilla 5:
-
Major improvements in the WebServices interface, including a new
REST-like endpoint, allowing clients to access data using standard HTTP
calls for easy development.
-
The UI has been significantly overhauled for a modern browsing
experience.
-
Performance improvements, including caching improvements to allow faster
access to certain types of data.
-
Red Hat Associates, Customers and Fedora Account System users can now
log in using SAML.
-
The addition of some of the Bayoteers extensions allowing features such
as inline editing of bugs in search results, team management and scrum
tools, etc.
-
Ye Olde diff viewer has been replaced with the modern diff2html diff
viewer
-
Improved, updated documentation including a rewrite using the
reStructuredText format, which allows documentation to be more easily
converted into different formats such as HTML and PDF, etc
The official release date for Bugzilla 5 will be determined based on the
beta feedback. We will communicate to you as the beta progresses.
For more information refer to:
https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html
https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html
https://beta-bugzilla.redhat.com/page.cgi?id=faq.html
https://beta-bugzilla.redhat.com/docs/en/html/using/index.html
https://beta-bugzilla.redhat.com/docs/en/html/api/index.html
Cheers, the Red Hat Bugzilla team.
1: https://beta-bugzilla.redhat.com/
2: https://lists.fedoraproject.org/archives/list/devel%40lists.
fedoraproject.org/
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
7 years, 7 months
[ OST Failure Report ] [ oVirt 4.1 ] [ 23-03-2017 ] [ 002_bootstrap.add_secondary_storage_domains ]
by Shlomo Ben David
Hi,
Test failed: [ 002_bootstrap.add_secondary_storage_domains ]
Link to suspected patches: N/A
Link to Job:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1054
Link to all logs:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1054/artifa...
Error snippet from the log:
<error>
2017-03-23 07:23:38,867-0400 ERROR (jsonrpc/2) [storage.TaskManager.Task]
(Task='8347d74c-92fe-4371-bc84-1314a43a2971') Unexpected error (task:870)
Traceback (most recent call last):
File "/usr/share/vdsm/storage/task.py", line 877, in _run
return fn(*args, **kargs)
File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 52, in
wrapper
res = f(*args, **kwargs)
File "/usr/share/vdsm/storage/hsm.py", line 1159, in attachStorageDomain
pool.attachSD(sdUUID)
File "/usr/lib/python2.7/site-packages/vdsm/storage/securable.py", line
79, in wrapper
return method(self, *args, **kwargs)
File "/usr/share/vdsm/storage/sp.py", line 924, in attachSD
dom = sdCache.produce(sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 112, in produce
domain.getRealDomain()
File "/usr/share/vdsm/storage/sdc.py", line 53, in getRealDomain
return self._cache._realProduce(self._sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 136, in _realProduce
domain = self._findDomain(sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 153, in _findDomain
return findMethod(sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 178, in _findUnfetchedDomain
raise se.StorageDomainDoesNotExist(sdUUID)
StorageDomainDoesNotExist: Storage domain does not exist:
(u'127fbe66-204c-4c6d-b521-d0f431af2b6c',)
</error>
Best Regards,
Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
RHCSA | RHCVA | RHCE
IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)
OPEN SOURCE - 1 4 011 && 011 4 1
7 years, 7 months
[ OST Failure Report ] [ oVirt master ] [ 20.4.17 ] [ add_secondary_storage_domains ]
by Gil Shinar
Test failed: add_secondary_storage_domains
Link to suspected patches:
Link to Job:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6403
Link to all logs:
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6403/art...
Error seems to be:
*2017-04-19 18:58:58,774-0400 ERROR (jsonrpc/2) [storage.TaskManager.Task]
(Task='8f9699ed-cc2f-434b-aa1e-b3c8ff30324a') Unexpected error
(task:871)Traceback (most recent call last): File
"/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 878, in _run
return fn(*args, **kargs) File
"/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 52, in wrapper
res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2709,
in getStorageDomainInfo dom = self.validateSdUUID(sdUUID) File
"/usr/share/vdsm/storage/hsm.py", line 298, in validateSdUUID sdDom =
sdCache.produce(sdUUID=sdUUID) File "/usr/share/vdsm/storage/sdc.py", line
112, in produce domain.getRealDomain() File
"/usr/share/vdsm/storage/sdc.py", line 53, in getRealDomain return
self._cache._realProduce(self._sdUUID) File
"/usr/share/vdsm/storage/sdc.py", line 136, in _realProduce domain =
self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 153,
in _findDomain return findMethod(sdUUID) File
"/usr/share/vdsm/storage/sdc.py", line 178, in _findUnfetchedDomain
raise se.StorageDomainDoesNotExist(sdUUID)StorageDomainDoesNotExist:
Storage domain does not exist:
(u'ac3bbc93-26ba-4ea8-8e76-c5b761f01931',)2017-04-19 18:58:58,777-0400 INFO
(jsonrpc/2) [storage.TaskManager.Task]
(Task='8f9699ed-cc2f-434b-aa1e-b3c8ff30324a') aborting: Task is aborted:
'Storage domain does not exist' - code 358 (task:1176)2017-04-19
18:58:58,777-0400 ERROR (jsonrpc/2) [storage.Dispatcher] {'status':
{'message': "Storage domain does not exist:
(u'ac3bbc93-26ba-4ea8-8e76-c5b761f01931',)", 'code': 358}} (dispatcher:78)*
7 years, 7 months
Announcing VM Portal 0.1.4
by Marek Libra
Hello All,
Let me announce availability of the VM Portal v0.1.4 for preliminary
testing.
We are looking forward to your feedback which we will try to incorporate
into oncoming stable 1.0.0 version.
The VM Portal aims to be a drop-in replacement of the existing Basic User
Portal.
Revised list of Extended User Portal features will be implemented to
ideally replace it as well.
The VM Portal is installed by default since oVirt 4.1.
*The simplest way to try latest version is via Docker by [1].*
Once oVirt credentials are entered and initialization is finished, you can
access it on [2].
If you prefer to stay as closest to the production setup as possible, the
latest rpms are available on project's yum repo [3].
Then you can access the portal from [4].
Prerequisites: The VM Portal requires ovirt-engine 4.0+, so far mostly
tested on 4.1.
Please note, the docker image is so far meant to just simplify user testing
and is not ready for production setup.
Unless decided otherwise in the future, stable releases are still planed to
be deployed via rpms.
For issue reporting or enhancement ideas, please use project's github issue
tracker [5].
Thank you for your feedback,
Marek
[1] docker run --rm -it -e ENGINE_URL=https://[OVIRT.ENGINE.FQDN]/ovirt-engine/
-p 3000:3000 mareklibra/ovirt-web-ui:latest
[2] http://localhost:3000
[3] https://people.redhat.com/mlibra/repos/ovirt-web-ui
[4] https://[OVIRT.ENGINE.FQDN]/ovirt-engine/web-ui
[5] https://github.com/oVirt/ovirt-web-ui/issues
--
Marek Libra
senior software engineer
Red Hat Czech
<https://www.redhat.com>
7 years, 7 months
Fwd: F27 Self Contained Change: Java 9
by Sandro Bonazzola
FYI
---------- Forwarded message ----------
From: Jan Kurik <jkurik(a)redhat.com>
Date: Wed, Apr 19, 2017 at 2:13 PM
Subject: F27 Self Contained Change: Java 9
To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>,
devel-announce(a)lists.fedoraproject.org
= Proposed Self Contained Change: Java 9 =
https://fedoraproject.org/wiki/Changes/Java9TechPreview
Change owner(s):
* Jiri Vanek <jvanek at redhat dot com>
Add a tech preview preview of the the upcoming version of Java
(OpenJDK9) to Fedora 27
== Detailed Description ==
The current Java implementation in Fedora comes from OpenJDK.
Java 9 (and OpenJDK9) are tentatively scheduled for release in
2017-07-27. Fedora 27 will most likely be out just a few months after
that, and is therefore positioned to receive a tech preview version of
the latest OpenJDK9 candidates. This preview should be released
version of Java 9, will contain new Java 9 APIs, but may not be
supported by many applications directly, therefore it have to warm up
as techpreview.
== Scope ==
The current version of OpenJDK 9 will be packaged and added to Fedora.
It will be a stand alone package and will not impact existing OpenJDK
8 packages.
Since this will be a tech preview, the primary JDK in Fedora 27 will
continue to be OpenJDK8. OpenJDK9 is not expected to be the primary
Java until Fedora 28 at least.
Two problems would generally be expected with a major JDK update based
on past experience:
FTFBS failures due to packages having a hard-coded JDK version dependency.
This was dealt with when both OpenJDK8 and OpenJDK7 were introduced
over Fedora 16/17 and Fedora 19/21. Now all Java dependent packages
should require java >= 1.6.0, and therefore this issue will not be a
problem any more.
There may be packages that rely on API that is deprecated in Java 9
Such packages cannot be identified until we actually start to build
with Java 9. Since Java 8 will continue to remain the primary version
of Java in Fedora 26, any API deprecation issues will be a secondary
problem as the main JVM will continue to be able to run everything
correctly. We expect to have everything resolved well before Java 9 is
to become the primary Java version in Fedora (F28 or later).
* Proposal owners:
providing java-9-openjdk package to main repositories
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
only the inclusion of new package is needed
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
7 years, 7 months
[VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode
by Roy Golan
I'm working on a POC lately on a change to stats collection and retrieval
by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
and report only core-business stuff to the engine. Engine will retrieve the
rest through a 3rd party provider (nevermind what is it atm)
Being backward compatible by design, I have to support 2 API versions for
Host.getStats , '4.1' and '4.2'.
Except from supplying less parameters, I want VDSM to do less stuff. It
doesn't need to sample what it doesn't report. In other words I want
'4.1-sampling' and '4.2-sampling'
# Introducing 'configuration' Verb:
As engine knows always(Hosted Engine as well) what cluster version this
host belongs to, it can configure VDSM to operate in cluster version mode.
Host.configure(config={version: 4.2}
Consider this verb, pre-activating using 'Host.getCaps' to set the context.
It will set the righjt sampling method, and other stuff if needed then API
endpoints will have the right permutation of the api to answer it.
4.2 host can operate in 4.1 mode:
Host.configure(config={version: 4.1}
Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
needs to know this is a new vdsm that has the verb available. One way to
overcome that is to fire the verb for every host regardless of the version
and disregard an error that implies the verb doesn't exist.
# Engine:
Engine will have a handling of the verb per version.
Host/Vms monitoring should be changed - I suggest to move out of the
monitoring code the whole stats collection as it is a different task which
is orthogonal to 'monitoring' and in 4.2 more than before.
I know configuration for VDSM has been discussed before and there are
probably tons of ways to do it. When you share your thoughts please
remember that configuration is a by-product of the effort.
Nevertheless it can be potentially beneficial to more functions in vdsm.
Thanks,
Roy
7 years, 7 months
