- Devel - oVirt List Archives

new storage domain question
by Hetz Ben Hamo 27 Aug '18

27 Aug '18

Hi, I just found something very interesting. While installing latest ovirt, I've created the shared_storage on my nas1 share folder (NFS). So far, so good. However, when trying to create additional 2 new storage domains, I can only create 1 (which means the shared_storage is 1 and a new one is 2, I cannot create a 3rd storage domain, 4th etc..). When I try, it shows an error (I don't remember which error right now). Why is that? and why this strange (IMHO) shared_storage thing? in a corporate, if I want to set up a virtualized environment, the storage administrator asks me which one I want (NFS, or an iSCSI LUN), do I need one or more, and then I'm adding them as a datastore (in VMWare, for example) and on top of that I'm installing the management software (for example, vCenter). with oVirt method, it will confuse VMware admins. Thanks

2 5

ovirt-engine has been tagged (ovirt-engine-4.2.6.4)
by Tal Nisan 26 Aug '18

26 Aug '18

1 0

vdsm has been tagged (v4.20.38)
by Milan Zamazal 24 Aug '18

24 Aug '18

Vdsm 4.20.38 for oVirt 4.2.6 rc3

1 0

Fwd: [CentOS-announce] Release for CentOS Linux 7 (1804) on POWER9 (ppc64le)
by Sandro Bonazzola 22 Aug '18

22 Aug '18

FYI ---------- Forwarded message ---------- From: James O'Connor <jpoc(a)linux.vnet.ibm.com> Date: 2018-08-15 20:26 GMT+02:00 Subject: [CentOS-announce] Release for CentOS Linux 7 (1804) on POWER9 (ppc64le) To: centos-announce(a)centos.org I am pleased to announce the general availability of CentOS Linux 7 (1804) for POWER9 processors (ppc64le - powerpc 64-bit little endian). This release is derived from Red Hat Enterprise Linux 7.5 ALT. Note this release is 99% equivalent to the existing CentOS 7 Linux 7 (1804) for POWER8 processors (ppc64le - powerpc 64-bit little endian). The key difference being that kernel-4.14.0 is used for POWER9 enablement and kernel-3.10.0 is used for POWER8 enablement. You will find the CentOS 7 (1804) Power9 installation images here: http://mirror.centos.org/altarch/7.5.1804/isos/power9/ sha256sum power9: 753c5b55c9ff681c925ec7d7c5295890284f40ec981f4da35b1f36f1ecbad95a CentOS-7-Power9-Everything-1804.iso 58d9af172656db71947b5db2d0d1f577217bbc1a86eada7ca3ce7bfcf7d7d9b4 CentOS-7-Power9-NetInstall-1804.iso CentOS 7 (1804) Power9 repositories: http://mirror.centos.org/altarch/7.5.1804/os/power9/ http://mirror.centos.org/altarch/7.5.1804/updates/power9/ http://mirror.centos.org/altarch/7.5.1804/extras/power9/ A special thank you to Johnny Hughes and Pablo Greco for their assistance making this release possible. -James O’Connor _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://www.redhat.com/en/events/red-hat-open-source-day-italia?sc_cid=701f…>

1 0

planned Jenkins restart
by Evgheni Dereveanchin 22 Aug '18

22 Aug '18

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new jobs will be scheduled during this maintenance period. I will inform you once it is over. Regards, Evgheni Dereveanchin

1 1

Is using CompensationContext in child commands broken?
by Andrej Krejcir 21 Aug '18

21 Aug '18

Hi, I'm changing UpdateClusterCommand to be non-transactive, and it would use CompensationContext for reverting DB operations. Reading through CommandBase code, I noticed the following flow seems to be broken: 1. A command without transaction is executed. 2. It executes a child command, with the compensation context of the current command. So that the result of the child command can be reverted if the parent fails. 3. Once the child command successfully finishes, it removes all entity snapshots from the DB (it calls CommandContext::cleanupCompensationDataAfterSuccessfulCommand), even if the snapshots were made by the parent command. See code at [1] and [2]. 4. The parent command then fails for some other reason, but its compensation context is empty, so the DB operations are not reverted correctly. Am I missing something or is this flow broken? Thanks, Andrej [1] - https://github.com/oVirt/ovirt-engine/blob/31fbb4cb48c7208e6b37c5c0e2756059… [2] - https://github.com/oVirt/ovirt-engine/blob/31fbb4cb48c7208e6b37c5c0e2756059…

3 2

Fwd: Fedora 30 System-Wide Change proposal: Mass Python 2 Package Removal
by Sandro Bonazzola 21 Aug '18

21 Aug '18

FYI ---------- Forwarded message ---------- From: Ben Cotton <bcotton(a)redhat.com> Date: 2018-08-20 22:41 GMT+02:00 Subject: Fedora 30 System-Wide Change proposal: Mass Python 2 Package Removal To: devel(a)lists.fedoraproject.org, devel-announce(a)lists.fedoraproject.org https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal == Summary == (Sub-)packages only providing python2 importable modules without additional functionality will be removed from Fedora unless some other package(s) depends on them. Python 2 will be deprecated in Fedora. Packagers can mark any other Python 2 packages as deprecated as well. == Owner == * Miro Hrončok (Churchyard) * Petr Viktorin (Pviktori) * Charalampos Stratakis (Cstratak) * Zbigniew Jędrzejewski-Szmek (Zbyszek) * Igor Gantenko (Ignatenkobrain) * Neal Gompa (Ngompa) == Detailed Description == Python 2 reaches End of Life on 2020-01-01. Its current maintainers would like to orphan it before that date, and so far no one else has stepped up to maintain Python 2 (with the full ecosystem) past 2020. Since thousands of packages still depend on python2, we need a more careful approach than normal orphaning. Some of those packages are abandoned and/or the Python 2 version is unnecessary. Others are useful and just need more time to port to Python 3. Hence we set up criteria for python2 packages that can remain in the distribution and we remove everything else. This should allow us to keep python2 for limited use, not break everything, but should also send a strong message that it is no longer a first class citizen, and filter packages we need to focus Python 3 porting efforts on. (Sub-)packages that only provide a python2 importable module, and are not required for other packages, will be removed. Examples of situations where a (sub-)package does not provide only the importable module: * A package also provides an application, mostly likely in /usr/bin, /usr/libexec... ** (Note that according to current guidelines, if the Python 3 version of a package provides the same functionality, the Python 3 package should provide the application.) ** (In certain situations the provided application is only useful to boostrap or manage projects using the module. Such applications don't count.) * A package provides a plugin for another application, most likely trough a setuptools entrypoint interface or some custom location on disk. Our process will be: * File bugs for all packages that look like they only provide a Python 2 importable module. (This includes those needed by other packages we plan to remove.) * Leave at least a week for packagers to respond to the bugs. * If the packager approves or there is no response for a week, we will remove the package. There are currently ~3000 source packages that generate python2 dependent RPMs. Automation is being created to be able to provide us a rough list of packages to remove. === Packages to remove === The list is at https://fedoraproject.org/wiki/Changes/Mass_Python_2_ Package_Removal/List not to disturb the reading experience of this page. Packagers can block some packages from removal by responding on Bugzilla and providing reasons. If no general consensus is reached, FESCo will decide (as Python SIG does not have a formal process for such decisions). We'll also actively try to remove unused or optional dependencies to reduce the number of packages that need to be kept because other packages depend on them. As dependencies evolve over time, we will regularly repeat this proces on rawhide from now on even on future releases. Packagers are strongly encouraged to help port their applications to Python 3. Removing old Python 2 only applications from Fedora is also encouraged, especially if the upstream is dead. Python SIG is available to help with porting. Packaging guidelines will be updated to reflect that packaging for Python 3 only is the default. Instructions for Python 2 and dual-support will be moved to the Appendix. Python 2 will be marked deprecated (see https://fedoraproject.org/wiki/Packaging:Deprecating_Packages) Any package that only provides a Python 2 importable module may be marked as deprecated as well if the maintainer(s) want to. == Benefit to Fedora == A giant pile of unneeded software running on a legacy interperter will be removed from Fedora before the interpreter stops being supported upstream. While we would very much like to remove Python 2 entirely, this way we are not breaking Fedora, and we can accomodate some exceptions. == Scope == * Proposal owners: ** Provide a list of packages to remove ** Collect feedback from affected packagers ** Retire the python2 only packages ** Remove python2 subpackages from dual-python packages * Other developers: ** Ask for packages to be removed from the list if needed (with reasons). ** Remove python2 subpackages from dual-python packages (not needed, but helpful) ** Optionaly mark remainign python2 packages deprecated * Policies and guidelines: ** Python packaging guidelines will be changed to only describe Python 3 ** Python 2 and dual-support packaging will be moved to the appendix ** Only packages providing additional features different than importable modules will be allowed to be added in Fedora (with exception for dependenecies of other packages) ** Python 2 will be marked deprecated https://fedoraproject.org/wiki/Packaging:Deprecating_Packages * Trademark approval: not needed for this Change == Upgrade/compatibility impact == Packages removed form Fedora repos will remain on the installed OS until explicitly removed by the user or obsoleted by the packagers. We'll only obsolete packages that would break upgrade (from fedora-obsolete-packages). == How To Test == Any program written in Python and any program that has Python plugins could potentially be influenced by this change. Testing is different for software that is still using Python 2 and for software that has been switched to Python 3. For any ''python2'' programs, make sure those programs are still functional after the package removal. Since various packages that are no longer built will not be removed from an existing system, just upgrading and checking packages is not enough. Either a new installation should be used, or after a branching point, any packages which haven't been rebuilt for F30, so any packages with .fc29 or lower release suffix should be removed from the system before testing. For the ''python3'' programs, install all upgrades and check if the software works. Upgrade failures because of missing dependencies should be treated as bugs. Any removed python2 subpackages which break upgrades need to be added to Obsoletes in fedora-obsolete-packages. == User Experience == There will be less Python 2 RPMs in Fedora repos. Users are encouraged to switch to Python 3 and/or use Python 2 virtual environments and pip for development. == Dependencies == Ideally, all programs that use python2 would be switched to use python3. Although we don't expect everything to be switched over, as much as possible should be, so that the set of remaining python2 subpackages is as small as possible. == Contingency Plan == * Contingency mechanism: ** If for some reason not everything is removed, nothing happens, it can be removed later. If for some reason something breaks, some packages can be unretired or restored. ** If someone steps up to maintain Python 2 (including the full ecosystem of packages now in Fedora), they can decide to discontinue removing packages, revert the Change, or come up with another plan. (Note that in this case, current maintainers will most likely orphan many fundamental python2 packages.) == Documentation == This page is the main documentation. Also see: https://pythonclock.org/ -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. fedoraproject.org/message/QRXWWZ2QG7JSZMAXNI6M6QMWV2XPCINM/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://www.redhat.com/en/events/red-hat-open-source-day-italia?sc_cid=701f…>

1 0

Question about ovirt python sdk4，gluster volume rebalance return none
by chokko＠126.com 21 Aug '18

21 Aug '18

when in version 3 sdk ,i use: req_cluster = api.clusters.get(id=c_uid) req_volume = req_cluster.glustervolumes.get(id=volume_id) req_volume.rebalance().job.get_id() to get a rebalance job id to trace if the job is finished. Now I use ovirt python sdk4 for develop: cluster = clustersservice.cluster_service(clusterid) volume = cluster.gluster_volumes_service().volume_service(volumeid) response=volume.rebalance() the response is none,how can i get the rebalance job id?

5 8

Please use package versions when building rpms
by Dafna Ron 16 Aug '18

16 Aug '18

Hi All, As some of you may have noticed, we have been having failures for some of the tests in master in the past 24 hours with the following yum error: https://pastebin.com/vqJCLgrP After some debugging we found that the issue is caused because the package which is failing had two different commits and no version set which caused two different packages with exactly the same name to be created. To solve this issue we would need the package to be re-build with a new version set. Here are the details on the package and how it failed. As you can see below we had two different commits creating two different packages by the same name: https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-image- template_standard-on-ghpush/30/ which was triggered by push: 00f5ffd4-a06e-11e8-8fc7-fa3846728ab0 https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-image- template_standard-on-ghpush/31/ which was triggered by push: 3dfc5996-a09b-11e8-856c-ec86908871c4 checking the packages that exist in the 4.2 and master tested repos I can see that we have the same exact name for two different packages: 4.2: ovirt-ansible-image-template-1.1.7-1.el7.noarch.rpm: Header SHA1 digest: OK (0033d83c3d8b6b0506767de3a4e44ffd64b2605c) MD5 digest: OK (2b6e87e53a51175aeac61662561c0e20) master: ovirt-ansible-image-template-1.1.7-1.el7.noarch.rpm: Header SHA1 digest: OK (597577a11775a7fc21207f3e76fe4df8a5030912) MD5 digest: OK (74bafadf2afae5f7797a90c982ad2767) This would cause yum to fail because we cannot have the same package name with different checksums. If anyone needs help in setting up versioning please contact myself or anyone from the CI team and we would be happy to assist. Thanks, Dafna

3 2

bugzilla priority?
by Hetz Ben Hamo 16 Aug '18

16 Aug '18

Hi, I've created this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1609029 This bug, IMHO, is *critical* - I want to build a PoC to a customer (before he decides to buy or not RHV) and this is embarrassing... Any chance this bug could get a higher prioritizing please? Thanks

2 1