[ovirt-devel] Re: Invalid value '-1' for 'cpu.max': Invalid argument
Hi,
please see my older message [1].
Hope this helps
Tomas
[1]
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MPSL3CDWNSMEZEVMN26DRHK4Z7DU6OH2/
On Sat, May 13, 2023 at 06:31:35PM +0200, lejeczek via Devel wrote:
> Hi guys.
>
> with latest stable ovirt node, hosted engine setup fails at, I guess late
> stage:
>
> ...
> [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Notify the user about a
> failure]
> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Host is
> not up, please check logs, perhaps also on the engine machine"}
>
> as setup sits & waits for a while, before it errors out, I see this in logs:
> ...
> 12687 still running (84875)
> Invalid value '-1' for 'cpu.max': Invalid argument
> 12687 still running (84870)
> 12687 still running (84865)
> 12687 still running (84860)
> Invalid value '-1' for 'cpu.max': Invalid argument
> ...
>
> and logs continue after engine setup has finished.
> I've browsed around but resolutions I found did not help, also I suspect it
> might be a bug thus any comments on how to fix it, are very much appreciated
> - btw,
> why BZs reports should go?
>
> many thanks, L.
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FVFGGKCD5HMT5PHX6PH7CXCXOEZEO7CY/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GG4FBQHGNKOVZGMHZIRNSTND6T6OZC6D/
[ovirt-devel] Re: for what is this used for?
Hi,
this is a libvirt issue that was already fixed. When to expect a fix in
centos I cannot say. See the related issues [1][2] for more info.
Tomas
[1] https://gitlab.com/libvirt/libvirt/-/issues/324
[2] https://github.com/oVirt/vdsm/issues/374
On Wed, Apr 05, 2023 at 06:48:16PM -, kleinbo...@gmail.com wrote:
> apparently it seems to break the upgrade of my engine to a newer version. any
> way to avoid this or where to fix it ? it appears, when the local external
> engine is deployed and tries to install the "new" host.
>
> Ty
>
> 2023-04-05 17:05:43,900+0200 ERROR (jsonrpc/4) [virt.vm]
> (vmId='299663c2-fca2-4394-b334-b639612eb4b8') Operation failed (vm:5605)
> Traceback (most recent call last):
> File "/usr/lib/python3.9/site-packages/vdsm/virt/vm.py", line 5570, in
> setCpuTuneQuota
> self._dom.setSchedulerParameters({'vcpu_quota': int(quota)})
> File "/usr/lib/python3.9/site-packages/vdsm/virt/virdomain.py", line 104,
> in f
> ret = attr(*args, **kwargs)
> File "/usr/lib/python3.9/site-packages/vdsm/common/libvirtconnection.py",
> line 114, in wrapper
> ret = f(*args, **kwargs)
> File "/usr/lib/python3.9/site-packages/vdsm/common/function.py", line 78,
> in wrapper
> return func(inst, *args, **kwargs)
> File "/usr/lib64/python3.9/site-packages/libvirt.py", line 2852, in
> setSchedulerParameters
> raise libvirtError('virDomainSetSchedulerParameters() failed')
> libvirt.libvirtError: Invalid value '-1' for 'cpu.max': Invalid argument
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2REVHZU3MCVPLKT4EJFFSIXFP5D33PH4/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MPSL3CDWNSMEZEVMN26DRHK4Z7DU6OH2/
[ovirt-devel] Gerrit host SSH key changed
Hi, it seems there was a change to host SSH keys on gerrit.ovirt.org. Can annyone comment on when and why that has happened? What is the new host key? Thanks, Tomas -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NEB5GYJMDNEQCHACHIOSSWFR5LLLCLRL/
[ovirt-devel] Re: Support for SSH keys other than RSA
On Mon, Feb 08, 2021 at 10:01:56AM +0100, Artur Socha wrote:
> Hi,
>
> I have been recently working on adding support for SSH keys other than
> RSA (communication between ovirt-engine and hosts(VDS-es)).
> The entire effort is tracked in Bugzilla [1].
Great, I've been really missing this. Looking forward to it.
Tomas
--
Tomáš Golembiovský
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/N7TJTWVFG6FUV3RGCSPSJHAKSVLHTJ3Q/
[ovirt-devel] Disk sizes not updated on unmap/discard
Hi, currently, when we run virt-sparsify on VM or user runs VM with discard enabled and when the disk is on block storage in qcow, the results are not reflected in oVirt. The blocks get discarded, storage can reuse them and reports correct allocation statistics, but oVirt does not. In oVirt one can still see the original allocation for disk and storage domain as it was before blocks were discarded. This is super-confusing to the users because when they check after running virt-sparsify and see the same values they think sparsification is not working. Which is not true. It all seems to be because of our LVM layout that we have on storage domain. The feature page for discard [1] suggests it could be solved by running lvreduce. But this does not seem to be true. When blocks are discarded the QCOW does not necessarily change its apparent size, the blocks don't have to be removed from the end of the disk. So running lvreduce is likely to remove valuable data. At the moment I don't see how we could achieve the correct values. If anyone has any idea feel free to entertain me. The only option seems to be to switch to LVM thin pools. Do we have any plans on doing that? Tomas [1] https://www.ovirt.org/develop/release-management/features/storage/pass-discard-from-guest-to-underlying-storage.html -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/LMTKRHYSRF5HSO7VO2GEVRBNOPGNRNUD/
[ovirt-devel] Re: Vdsm CI for el8 is broken
On Tue, 23 Jun 2020 17:36:25 +0200 Dominik Holler wrote: > On Tue, Jun 23, 2020 at 5:22 PM Tomáš Golembiovský > wrote: > > > On Tue, 23 Jun 2020 12:49:47 +0200 > > Dominik Holler wrote: > > > > > On Tue, Jun 23, 2020 at 12:07 PM Milan Zamazal > > wrote: > > > > > > > Dominik Holler writes: > > > > > > > > > On Mon, Jun 22, 2020 at 9:34 AM Milan Zamazal > > > > > > wrote: > > > > > > > > > >> Nir Soffer writes: > > > > >> > > > > >> > On Sun, Jun 21, 2020 at 1:18 PM Amit Bawer > > wrote: > > > > >> >> > > > > >> >> Hi > > > > >> > > > > > >> >> > > > > >> >> Seems that in the last few days the el8 CI for vdsm cannot run, > > were > > > > >> there any el8 repo changes? > > > > >> >> > > > > >> >> [2020-06-21T09:20:03.003Z] Mock Version: 2.2 > > > > >> >> [2020-06-21T09:20:03.003Z] INFO: Mock Version: 2.2 > > > > >> >> [2020-06-21T09:20:03.987Z] Start: dnf install > > > > >> >> [2020-06-21T09:20:12.326Z] ERROR: Command failed: > > > > >> >> [2020-06-21T09:20:12.326Z] # /usr/bin/dnf --installroot > > > > >> >> > > > > > > /var/lib/mock/epel-8-x86_64-8e9eeb575ab4da7bf0fbfdc80a25b9c0-30232/root/ > > > > >> >> --releasever 8 --setopt=deltarpm=False --allowerasing > > > > >> >> --disableplugin=local --disableplugin=spacewalk > > > > >> >> --disableplugin=local --disableplugin=spacewalk install dnf tar > > > > >> >> gcc-c++ redhat-rpm-config which xz sed make bzip2 gzip gcc > > coreutils > > > > >> >> unzip shadow-utils diffutils cpio bash gawk rpm-build info patch > > > > >> >> util-linux findutils grep python36 autoconf automake createrepo > > dnf > > > > >> >> dnf-utils e2fsprogs gcc gdb git iproute-tc iscsi-initiator-utils > > > > >> >> libguestfs-tools-c lshw make openvswitch ovirt-imageio-common > > > > >> >> python3-augeas python3-blivet python3-coverage python3-dateutil > > > > >> >> python3-dbus python3-decorator python3-devel python3-dmidecode > > > > >> >> python3-inotify python3-ioprocess-1.4.1 python3-libselinux > > > > >> >> python3-libvirt python3-magic python3-netaddr python3-nose > > > > >> >> python3-pip python3-policycoreutils python3-pyyaml > > python3-requests > > > > >> >> python3-sanlock python3-six python3-yaml rpm-build rpmlint > > sanlock > > > > >> >> sudo systemd-udev xfsprogs --setopt=tsflags=nocontexts > > > > >> >> [2020-06-21T09:20:12.326Z] No matches found for the following > > > > >> >> disable plugin patterns: local, spacewalk > > > > >> >> [2020-06-21T09:20:12.326Z] Last metadata expiration check: > > 0:00:02 > > > > ago > > > > >> on Sun Jun 21 09:20:07 2020. > > > > >> >> [2020-06-21T09:20:12.326Z] No match for argument: openvswitch > > > > >> >> [2020-06-21T09:20:12.326Z] Error: Unable to find a match: > > openvswitch > > > > >> >> > > > > > > > > > > That > > > https://gerrit.ovirt.org/#/c/109714/ > > > was required to fix this raises the question from which repo openvswitch > > > was consumed before. > > > But never mind, it is fixed now. > > > > What exactly is fixed? It is still failing for me for the same reason. > > > > > The error > [2020-06-21T09:20:12.326Z] No match for argument: openvswitch > [2020-06-21T09:20:12.326Z] Error: Unable to find a match: openvswitch > is fixed by adding the ovirt44testing repo. Well the last CI state on that patch is -1, that does not look like a fix too much. But if it is, could we rebease & merge it? Tomas > > > > > Tomas > > > > > > > > > > > > >> >> Taken from > > > > >> > > > > > > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/21966/consoleText > > > > > > >> > > > > > >> > I think this is a result
[ovirt-devel] Re: Vdsm CI for el8 is broken
On Tue, 23 Jun 2020 12:49:47 +0200 Dominik Holler wrote: > On Tue, Jun 23, 2020 at 12:07 PM Milan Zamazal wrote: > > > Dominik Holler writes: > > > > > On Mon, Jun 22, 2020 at 9:34 AM Milan Zamazal > > wrote: > > > > > >> Nir Soffer writes: > > >> > > >> > On Sun, Jun 21, 2020 at 1:18 PM Amit Bawer wrote: > > >> >> > > >> >> Hi > > >> > > > >> >> > > >> >> Seems that in the last few days the el8 CI for vdsm cannot run, were > > >> there any el8 repo changes? > > >> >> > > >> >> [2020-06-21T09:20:03.003Z] Mock Version: 2.2 > > >> >> [2020-06-21T09:20:03.003Z] INFO: Mock Version: 2.2 > > >> >> [2020-06-21T09:20:03.987Z] Start: dnf install > > >> >> [2020-06-21T09:20:12.326Z] ERROR: Command failed: > > >> >> [2020-06-21T09:20:12.326Z] # /usr/bin/dnf --installroot > > >> >> > > /var/lib/mock/epel-8-x86_64-8e9eeb575ab4da7bf0fbfdc80a25b9c0-30232/root/ > > >> >> --releasever 8 --setopt=deltarpm=False --allowerasing > > >> >> --disableplugin=local --disableplugin=spacewalk > > >> >> --disableplugin=local --disableplugin=spacewalk install dnf tar > > >> >> gcc-c++ redhat-rpm-config which xz sed make bzip2 gzip gcc coreutils > > >> >> unzip shadow-utils diffutils cpio bash gawk rpm-build info patch > > >> >> util-linux findutils grep python36 autoconf automake createrepo dnf > > >> >> dnf-utils e2fsprogs gcc gdb git iproute-tc iscsi-initiator-utils > > >> >> libguestfs-tools-c lshw make openvswitch ovirt-imageio-common > > >> >> python3-augeas python3-blivet python3-coverage python3-dateutil > > >> >> python3-dbus python3-decorator python3-devel python3-dmidecode > > >> >> python3-inotify python3-ioprocess-1.4.1 python3-libselinux > > >> >> python3-libvirt python3-magic python3-netaddr python3-nose > > >> >> python3-pip python3-policycoreutils python3-pyyaml python3-requests > > >> >> python3-sanlock python3-six python3-yaml rpm-build rpmlint sanlock > > >> >> sudo systemd-udev xfsprogs --setopt=tsflags=nocontexts > > >> >> [2020-06-21T09:20:12.326Z] No matches found for the following > > >> >> disable plugin patterns: local, spacewalk > > >> >> [2020-06-21T09:20:12.326Z] Last metadata expiration check: 0:00:02 > > ago > > >> on Sun Jun 21 09:20:07 2020. > > >> >> [2020-06-21T09:20:12.326Z] No match for argument: openvswitch > > >> >> [2020-06-21T09:20:12.326Z] Error: Unable to find a match: openvswitch > > >> >> > > > > That > https://gerrit.ovirt.org/#/c/109714/ > was required to fix this raises the question from which repo openvswitch > was consumed before. > But never mind, it is fixed now. What exactly is fixed? It is still failing for me for the same reason. Tomas > > > > >> >> Taken from > > >> > > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/21966/consoleText > > >> > > > >> > I think this is a result of trying to move to CentOS 8.2 before all > > >> > the packages are > > >> > ready. > > >> > > >> There are problems with openvswitch package since the CentOS 8.2 update. > > >> It also blocks Vdsm builds. Sandro and Dominik work on solving it. > > >> > > >> > > > This seems to be something unrelated in the build system. > > > CI should work since last Tuesday again. > > > > I'm not sure which CI you mean, but Vdsm CI on master is still broken, > > even with Sandro's patch adding the oVirt 4.4 virt repo > > (https://gerrit.ovirt.org/109714): > > > > Running transaction check > > [2020-06-22T08:54:51.868Z] warning: Generating 18 missing index(es), > > please wait... > > [2020-06-22T08:54:51.868Z] Error: transaction check vs depsolve: > > [2020-06-22T08:54:51.868Z] /bin/sh is needed by > > ovirt-openvswitch-2.11-0.2020061801.el8.noarch > > [2020-06-22T08:54:51.868Z] bash is needed by > > ovirt-openvswitch-2.11-0.2020061801.el8.noarch > > [2020-06-22T08:54:51.868Z] systemd is needed by > > ovirt-openvswitch-2.11-0.2020061801.el8.noarch > > [2020-06-22T08:54:51.868Z] To diagnose the problem, try running: 'rpm >
[ovirt-devel] Re: 4.4 beta - systemd & pids - daemon fails
Today I tried to downgrade systemd to 239-18 and then upgrade again to
see what will happen. And yes, it is definitely caused by change in
systemd. Likely this change (BZ 1778384):
https://github.com/systemd-rhel/rhel-8/pull/44
But I don't know where to report the problem for CentOS Stream. The
'openvswitch' component in Bugzilla is not active anymore. Does anyone
know what's the proper component?
Tomas Golembiovsky
On Fri, 15 May 2020 00:02:00 +0200
Tomáš Golembiovský wrote:
> Sorry for late reply, but I noticed the email just now. I had the same
> problem some time ago but could not figure out the source of it at that
> time. I noticed the behavior after some system update and reboot, but
> neither systemd nor openvswitch had been updated at that moment. Now I
> noticed that the host where things are broken contains
> systemd-239-21.el8 from CentOS Stream and host where everything works
> systemd-239-18.el8_1.5 from normal CentOS. so it is possible that
> systemd was updated on previous "dnf update" and I just forgot to reboot
> the host so the problem did not manifest itself. So the question is, are
> you perhaps using CentOS Stream on your host?
>
> As to why I suspect systemd, mostly because the unit file in openvswitch
> had not changed for a long time. The management of runtime directory is
> left to systemd (see the RuntimeDirectory* variables in unit file). As
> per documentation the owner is the same as the User in the unit file, or
> it defaults to root if not specified. That is our case here. The
> openvswitch unit file "cleverly" solves it by calling "chown" in
> ExecStartPre. The trouble is that the permission and owner of the
> runtime directory are "fixed" by systemd after every Exec* command so
> the chown does not do its job. It is likely that this behavior changed
> in systemd between 239-18 and 239-21.
>
> My workaround was simply to do that as part of ExecStart like this:
>
> ExecStart=/bin/sh -x -c '/usr/bin/chown ${OVS_USER_ID}
> /var/run/openvswitch /var/log/openvswitch ;
> /usr/share/openvswitch/scripts/ovs-ctl \
> --no-ovs-vswitchd --no-monitor --system-id=random \
> ${OVSUSER} \
> start $OPTIONS'
>
> Hope this helps,
>
> Tomas Golebiovsky
>
>
> PS: The reason why you don't see the runtime directory on disk is that
> it is removed by systemd when the service stops. That's why creating it
> or changing the permission on it manually makes no sense. Or having it
> listed as RPM content.
>
>
> On Mon, 4 May 2020 14:51:57 +0100
> lejeczek wrote:
>
> > On 04/05/2020 13:59, Yedidyah Bar David wrote:
> > > On Mon, May 4, 2020 at 3:37 PM lejeczek wrote:
> > >>
> > >>
> > >> On 04/05/2020 12:07, Yedidyah Bar David wrote:
> > >>> On Mon, May 4, 2020 at 1:49 PM lejeczek wrote:
> > >>>> hi devel,
> > >>>>
> > >>>> Some inconsistencies in systemd's daemon configs &/|| binaries?
> > >>>>
> > >>>> Starting Open vSwitch Database Unit...
> > >>>> ovs|2|daemon_unix|EMER|/var/run/openvswitch/ovsdb-server.pid.tmp:
> > >>>> create failed (Permission denied)
> > >>>> Starting ovsdb-server ovsdb-server:
> > >>>> /var/run/openvswitch/ovsdb-server.pid.tmp: create failed
> > >>>> (Permission denied)
> > >>>> [FAILED]
> > >>>>
> > >>>> Any quick fix would mind to suggest?
> > >>> Can you please check/share the output of:
> > >>>
> > >>> ls -la /var/run/openvswitch
> > >>>
> > >>> rpm -q openvswitch
> > >>>
> > >>> Best regards,
> > >> $ ls -la /var/run/openvswitch
> > >> ls: cannot access '/var/run/openvswitch
> > > So it's gone,
> > >
> > >> $ rpm -ql openvswitch.x86_64
> > >> /etc/bash_completion.d/ovs-appctl-bashcomp.bash
> > >> /etc/bash_completion.d/ovs-vsctl-bashcomp.bash
> > >> /etc/logrotate.d/openvswitch
> > >> /etc/openvswitch
> > >> /etc/openvswitch/.conf.db.~lock~
> > >> /etc/openvswitch/conf.db
> > >> /etc/openvswitch/default.conf
> > >> /etc/openvswitch/system-id.conf
> > >> /etc/sysconfig/openvswitch
> > >> /run/openvswitch
> > >> /usr/bin/ovs-appctl
> > >> /usr/bin/ovs-dpctl
> > >> /usr/bin/ovs-ofctl
> > >> /usr/bin/ovs-pki
> >
[ovirt-devel] Re: 4.4 beta - systemd & pids - daemon fails
/usr/lib/.build-id/5e/886639c0e4841d01cfa9d6a8aff210f297267e > >> /usr/lib/.build-id/6c > >> /usr/lib/.build-id/6c/ad54943c22a0ec765f339e4f4216b51a809dc9 > >> /usr/lib/.build-id/6e > >> /usr/lib/.build-id/6e/cd97bce86b69ce1a9841b84540884ad7b7421f > >> /usr/lib/.build-id/78 > >> /usr/lib/.build-id/78/a71d93990610e97e76a7b1b4acc105e64655a3 > >> /usr/lib/.build-id/a9 > >> /usr/lib/.build-id/a9/62872e830ac6c7db512b8fd17c7ae9d9227e7e > >> /usr/lib/.build-id/aa > >> /usr/lib/.build-id/aa/7a8f137a95a94eedb767aecbed27834ba906a9 > >> /usr/lib/.build-id/dc > >> /usr/lib/.build-id/dc/a8f35e4acbbcf599b63369081d5643ce679ded > >> /usr/lib/.build-id/ee > >> /usr/lib/.build-id/ee/57eca75e3312ed9cad7fbad6977fc06bd4852f > >> /usr/lib/systemd/system/openvswitch.service > >> /usr/lib/systemd/system/ovs-delete-transient-ports.service > >> /usr/lib/systemd/system/ovs-vswitchd.service > >> /usr/lib/systemd/system/ovsdb-server.service > >> /usr/lib/udev/rules.d/91-vfio.rules > >> /usr/lib64/libofproto-2.11.so.0 > >> /usr/lib64/libofproto-2.11.so.0.0.1 > >> /usr/lib64/libopenvswitch-2.11.so.0 > >> /usr/lib64/libopenvswitch-2.11.so.0.0.1 > >> /usr/lib64/libovn-2.11.so.0 > >> /usr/lib64/libovn-2.11.so.0.0.1 > >> /usr/lib64/libovsdb-2.11.so.0 > >> /usr/lib64/libovsdb-2.11.so.0.0.1 > >> /usr/lib64/libsflow-2.11.so.0 > >> /usr/lib64/libsflow-2.11.so.0.0.1 > >> /usr/lib64/libvtep-2.11.so.0 > >> /usr/lib64/libvtep-2.11.so.0.0.1 > >> /usr/sbin/ovs-vswitchd > >> /usr/sbin/ovsdb-server > >> /usr/share/doc/openvswitch > >> /usr/share/doc/openvswitch/LICENSE > >> /usr/share/doc/openvswitch/NEWS > >> /usr/share/doc/openvswitch/NOTICE > >> /usr/share/doc/openvswitch/README.RHEL.rst > >> /usr/share/doc/openvswitch/README.rst > >> /usr/share/man/man1/ovsdb-client.1.gz > >> /usr/share/man/man1/ovsdb-server.1.gz > >> /usr/share/man/man1/ovsdb-tool.1.gz > >> /usr/share/man/man5/ovs-vswitchd.conf.db.5.gz > >> /usr/share/man/man5/ovsdb-server.5.gz > >> /usr/share/man/man5/ovsdb.5.gz > >> /usr/share/man/man5/vtep.5.gz > >> /usr/share/man/man7/ovs-actions.7.gz > >> /usr/share/man/man7/ovs-fields.7.gz > >> /usr/share/man/man7/ovsdb-server.7.gz > >> /usr/share/man/man7/ovsdb.7.gz > >> /usr/share/man/man8/ovs-appctl.8.gz > >> /usr/share/man/man8/ovs-ctl.8.gz > >> /usr/share/man/man8/ovs-dpctl.8.gz > >> /usr/share/man/man8/ovs-kmod-ctl.8.gz > >> /usr/share/man/man8/ovs-ofctl.8.gz > >> /usr/share/man/man8/ovs-parse-backtrace.8.gz > >> /usr/share/man/man8/ovs-pki.8.gz > >> /usr/share/man/man8/ovs-vsctl.8.gz > >> /usr/share/man/man8/ovs-vswitchd.8.gz > >> /usr/share/man/man8/vtep-ctl.8.gz > >> /usr/share/openvswitch/scripts/openvswitch.init > >> /usr/share/openvswitch/scripts/ovs-check-dead-ifs > >> /usr/share/openvswitch/scripts/ovs-ctl > >> /usr/share/openvswitch/scripts/ovs-kmod-ctl > >> /usr/share/openvswitch/scripts/ovs-lib > >> /usr/share/openvswitch/scripts/ovs-save > >> /usr/share/openvswitch/scripts/ovs-systemd-reload > >> /usr/share/openvswitch/scripts/ovs-vtep > >> /usr/share/openvswitch/vswitch.ovsschema > >> /usr/share/openvswitch/vtep.ovsschema > >> /var/lib/openvswitch > >> /var/lib/openvswitch/pki > > ...although the package did include it. > > > > Perhaps check what/who removed it. > > > > To fix, you can try 'yum reinstall openvswitch'. > > > > Best regards, > Nope, trivializing it won't help. > It's something in the either or both, systemd deamons > configs, binaries/configs. > Even a manual creation of the path: > $ mkdir /var/run/openvswitch/; chown openvswitch:hugetlbfs > /var/run/openvswitch/ > Does nothing because very next attempt of: > $ systemctl restart openvswitch.service > and that end path is gone. > > regards, L > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IG3QDCTIUSSFZETZJ6UF4MYFFP33VKZP/ -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/RL4PCBDHFZYTITDKOXHV3VQLCUZGKA4T/
[ovirt-devel] Re: CI environment broken
Thanks Marcin
On Tue, Feb 11, 2020 at 02:28:58PM +0100, Marcin Sobczyk wrote:
> Hi,
>
> please see https://gerrit.ovirt.org/#/c/106877/
>
> Regards, Marcin
>
> On 2/11/20 1:55 PM, Tomáš Golembiovský wrote:
> > Oh yes, and here is the example of failure:
> >
> > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/18064/artifact/ci_build_summary.html
> > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/18064//artifact/check-patch.tests-py3.el8.x86_64/mock_logs/script/stdout_stderr.log
> > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/18064//artifact/check-patch.linters.fc30.x86_64/mock_logs/script/stdout_stderr.log
> >
> >
> >
> > On Tue, Feb 11, 2020 at 01:51:16PM +0100, Tomáš Golembiovský wrote:
> > > Hi,
> > >
> > > it looks like the CI is broken. All recent Gerrit patches fail currently
> > > for strange reasons.
> > >
> > >
> > > check-patch.linters.fc30.x86_64 fails because it cannot create tox
> > > environments:
> > >
> > > > ERROR: invocation failed (exit code 1), logfile:
> > > > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/gluster/log/gluster-0.log
> > > > == log start
> > > > ===
> > > > ERROR:root:ImportError: cannot import name 'ensure_text'
> > > >
> > > > === log end
> > > >
> > > > ERROR: InvocationError for command /usr/bin/python3 -m virtualenv
> > > > --system-site-packages --no-download --python /usr/bin/python3 gluster
> > > > (exited with code 1)
> > >
> > > check-patch.tests-py3.el8.x86_64 fails on flake8 because it tries to
> > > lint files from some virtual env:
> > >
> > > > ...
> > > > /.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:48:1:
> > > > E266 too many leading '#' for block comment
> > > > ### encodings module API
> > > > ^
> > > > ./.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:61:1:
> > > > E266 too many leading '#' for block comment
> > > > ### Decoding Table
> > > > ^
> > > > ./.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:324:1:
> > > > E266 too many leading '#' for block comment
> > > > ### Encoding table
> > > > ^
> > > > 6 E111 indentation is not a multiple of four
> > > > 15E114 indentation is not a multiple of four (comment)
> > > > 12E115 expected an indented block (comment)
> > > > 70E116 unexpected indentation (comment)
> > > > 38E121 continuation line under-indented for hanging indent
> > > > 10177 E122 continuation line missing indentation or outdented
> > > > 12E123 closing bracket does not match indentation of opening
> > > > bracket's line
> > > > 2 E124 closing bracket does not match visual indentation
> > > > 1 E125 continuation line with same indent as next logical line
> > > > 37E126 continuation line over-indented for hanging indent
> > > > 78E127 continuation line over-indented for visual indent
> > > > 124 E128 continuation line under-indented for visual indent
> > > > 19E129 visually indented line with same indent as next logical line
> > > > 253 E131 continuation line unaligned for hanging indent
> > > > 962 E201 whitespace after '{'
> > > > 982 E202 whitespace before '}'
> > > > 11E211 whitespace before '('
> > > > 143 E221 multiple spaces before operator
> > > > 61E225 missing whitespace around operator
> > > > 229 E226 missing whitespace around arithmetic operator
> > > > 4 E227 missing whitespace around bitwise or shift operator
> > > > 56614 E231 missing whitespace after ','
> > > > 1024 E241 multiple spaces after ','
> > > > 36E251 unexpected spaces around keyword / parameter equals
> > > > 770 E261 at least two spaces before inline comment
> > > > 205 E262 inline comment should start with '# '
> > > > 190 E265 block
[ovirt-devel] Re: CI environment broken
Oh yes, and here is the example of failure:
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/18064/artifact/ci_build_summary.html
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/18064//artifact/check-patch.tests-py3.el8.x86_64/mock_logs/script/stdout_stderr.log
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/18064//artifact/check-patch.linters.fc30.x86_64/mock_logs/script/stdout_stderr.log
On Tue, Feb 11, 2020 at 01:51:16PM +0100, Tomáš Golembiovský wrote:
> Hi,
>
> it looks like the CI is broken. All recent Gerrit patches fail currently
> for strange reasons.
>
>
> check-patch.linters.fc30.x86_64 fails because it cannot create tox
> environments:
>
> > ERROR: invocation failed (exit code 1), logfile:
> > /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/gluster/log/gluster-0.log
> > == log start
> > ===
> > ERROR:root:ImportError: cannot import name 'ensure_text'
> >
> > === log end
> >
> > ERROR: InvocationError for command /usr/bin/python3 -m virtualenv
> > --system-site-packages --no-download --python /usr/bin/python3 gluster
> > (exited with code 1)
>
>
> check-patch.tests-py3.el8.x86_64 fails on flake8 because it tries to
> lint files from some virtual env:
>
> > ...
> > /.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:48:1:
> > E266 too many leading '#' for block comment
> > ### encodings module API
> > ^
> > ./.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:61:1:
> > E266 too many leading '#' for block comment
> > ### Decoding Table
> > ^
> > ./.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:324:1:
> > E266 too many leading '#' for block comment
> > ### Encoding table
> > ^
> > 6 E111 indentation is not a multiple of four
> > 15E114 indentation is not a multiple of four (comment)
> > 12E115 expected an indented block (comment)
> > 70E116 unexpected indentation (comment)
> > 38E121 continuation line under-indented for hanging indent
> > 10177 E122 continuation line missing indentation or outdented
> > 12E123 closing bracket does not match indentation of opening bracket's
> > line
> > 2 E124 closing bracket does not match visual indentation
> > 1 E125 continuation line with same indent as next logical line
> > 37E126 continuation line over-indented for hanging indent
> > 78E127 continuation line over-indented for visual indent
> > 124 E128 continuation line under-indented for visual indent
> > 19E129 visually indented line with same indent as next logical line
> > 253 E131 continuation line unaligned for hanging indent
> > 962 E201 whitespace after '{'
> > 982 E202 whitespace before '}'
> > 11E211 whitespace before '('
> > 143 E221 multiple spaces before operator
> > 61E225 missing whitespace around operator
> > 229 E226 missing whitespace around arithmetic operator
> > 4 E227 missing whitespace around bitwise or shift operator
> > 56614 E231 missing whitespace after ','
> > 1024 E241 multiple spaces after ','
> > 36E251 unexpected spaces around keyword / parameter equals
> > 770 E261 at least two spaces before inline comment
> > 205 E262 inline comment should start with '# '
> > 190 E265 block comment should start with '# '
> > 91E266 too many leading '#' for block comment
> > 3 E271 multiple spaces after keyword
> > 4 E272 multiple spaces before keyword
> > 71E301 expected 1 blank line, found 0
> > 427 E302 expected 2 blank lines, found 1
> > 26E303 too many blank lines (3)
> > 26E306 expected 1 blank line before a nested definition, found 0
> > 3 E401 multiple imports on one line
> > 4717 E501 line too long (96 > 79 characters)
> > 5 E502 the backslash is redundant between brackets
> > 11E701 multiple statements on one line (colon)
> > 11E704 multiple statements on one line (def)
> > 4 E713 test for membership should be 'not in'
> > 1 E714 test for object identity should be 'is not'
> > 565 F401 'typing.List' impor
[ovirt-devel] CI environment broken
Hi,
it looks like the CI is broken. All recent Gerrit patches fail currently
for strange reasons.
check-patch.linters.fc30.x86_64 fails because it cannot create tox environments:
> ERROR: invocation failed (exit code 1), logfile:
> /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/.tox/gluster/log/gluster-0.log
> == log start
> ===
> ERROR:root:ImportError: cannot import name 'ensure_text'
>
> === log end
>
> ERROR: InvocationError for command /usr/bin/python3 -m virtualenv
> --system-site-packages --no-download --python /usr/bin/python3 gluster
> (exited with code 1)
check-patch.tests-py3.el8.x86_64 fails on flake8 because it tries to
lint files from some virtual env:
> ...
> /.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:48:1:
> E266 too many leading '#' for block comment
> ### encodings module API
> ^
> ./.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:61:1:
> E266 too many leading '#' for block comment
> ### Decoding Table
> ^
> ./.local/share/virtualenv/seed-v1/3.7/image/SymlinkPipInstall/pip-20.0.2-py2.py3-none-any/pip/_vendor/webencodings/x_user_defined.py:324:1:
> E266 too many leading '#' for block comment
> ### Encoding table
> ^
> 6 E111 indentation is not a multiple of four
> 15E114 indentation is not a multiple of four (comment)
> 12E115 expected an indented block (comment)
> 70E116 unexpected indentation (comment)
> 38E121 continuation line under-indented for hanging indent
> 10177 E122 continuation line missing indentation or outdented
> 12E123 closing bracket does not match indentation of opening bracket's
> line
> 2 E124 closing bracket does not match visual indentation
> 1 E125 continuation line with same indent as next logical line
> 37E126 continuation line over-indented for hanging indent
> 78E127 continuation line over-indented for visual indent
> 124 E128 continuation line under-indented for visual indent
> 19E129 visually indented line with same indent as next logical line
> 253 E131 continuation line unaligned for hanging indent
> 962 E201 whitespace after '{'
> 982 E202 whitespace before '}'
> 11E211 whitespace before '('
> 143 E221 multiple spaces before operator
> 61E225 missing whitespace around operator
> 229 E226 missing whitespace around arithmetic operator
> 4 E227 missing whitespace around bitwise or shift operator
> 56614 E231 missing whitespace after ','
> 1024 E241 multiple spaces after ','
> 36E251 unexpected spaces around keyword / parameter equals
> 770 E261 at least two spaces before inline comment
> 205 E262 inline comment should start with '# '
> 190 E265 block comment should start with '# '
> 91E266 too many leading '#' for block comment
> 3 E271 multiple spaces after keyword
> 4 E272 multiple spaces before keyword
> 71E301 expected 1 blank line, found 0
> 427 E302 expected 2 blank lines, found 1
> 26E303 too many blank lines (3)
> 26E306 expected 1 blank line before a nested definition, found 0
> 3 E401 multiple imports on one line
> 4717 E501 line too long (96 > 79 characters)
> 5 E502 the backslash is redundant between brackets
> 11E701 multiple statements on one line (colon)
> 11E704 multiple statements on one line (def)
> 4 E713 test for membership should be 'not in'
> 1 E714 test for object identity should be 'is not'
> 565 F401 'typing.List' imported but unused
> 4 F403 'from .core import *' used; unable to detect undefined names
> 2 F405 'encode' may be undefined, or defined from star imports: .codec,
> .core
> 3 F811 redefinition of unused 're' from line 10
> 78F821 undefined name 'unicode'
> 23F841 local variable 'success' is assigned to but never used
> 158 W291 trailing whitespace
> 259 W293 blank line contains whitespace
> 12W391 blank line at end of file
Are the environemtns broken? Can somebody look into that?
Tomas
--
Tomáš Golembiovský
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2BN4SV6NRDL2L5VEIFLVISJGF3SYYG6J/
[ovirt-devel] Re: Access to images in block domain from more VMs
On Tue, Jul 09, 2019 at 09:18:27AM -0700, Michal Skrivanek wrote: > > On 9 Jul 2019, at 15:37, Tomáš Golembiovský wrote: > > > > On Thu, 4 Jul 2019 23:59:07 +0300 > > Nir Soffer wrote: > > > >> On Tue, Jul 2, 2019 at 1:41 PM Tomáš Golembiovský > >> wrote: > >> > >>> Hi, > >>> > >>> we have a large gap in handling ISO files in data domains and especially > >>> on block domains. None of the flows that work with ISOs works (well, one > >>> sort of does): > >>> > >>> 1) Change CD for running VM [1] > >>> > >> > >> Broken because VM.changeCD accepts a path instead of PDIV. > >> > >> This used to work with ISO domain since file based storage does not need > >> to be prepared, but with block storage someone must prepare the ISO image > >> before using it and tear down the image when done. > >> > >> If you send PDIV to vdsm vdsm will prepare the image and tear it down > >> and use the correct path to the image. > >> > >> > >>> 2) Attaching boot disk in Run Once -- this works but I wonder if it's by > >>> accident, because engine issues spurious teardown on images [2] > >>> > >> > >> Can you point to more info about "spurious teardown"? > > > > See the linked bug [2]. When you configure same ISO to two VMs on the > > same host, engine tries to teardown the image after first VM is powered > > off while second VM is still using it. It is similar to the upload-flow > > you described below. > > > > > >> > >>> 3) Guest tools during VM import [3] > >>> > >> > >> Looks like [2] and [3] are the same. We don't know what > >> "Guest tools during VM import" means. > > > > When importing a VM user has an option to pick ISO with Windows drivers. > > The drivers will be injected into the VM during import. Same as 1) this > > relied on the fact that paths to ISO domain don't change and passed the > > path in API. > > > > > >> > >>> 4) Automatic attach of guest tools to Windows VMs > >>> > >> > >> I don't have any idea what is this automatic attach. > > > > Engine automatically picks guest tools ISO and adds it to the VM > > definition for you when you start Windows guest with old guest tools. > > Our main problem here is not related to prepare/teardown. We didn't get > > that far yet. :) Right now the issue is that the ISOs in data domains > > are not checked when searching for the latest ISO. > > > > > >> > >> Before virt can fix all those we need input from storage on how we > >>> should handle the images on block domains. > >> > >> > >> You should handle ISO images in the same way for all domains: > >> - never assume any path on the host, you should not care about the path, > >> and it is different for iso/data file/data block. > >> - If you start a vm with a ISO, or plug/unplug, always use PDIV and let > >> vdsm > >> prepare and teardown the image for you, and update the xml with the > >> correct > >> path > >> - if you need to access the ISO externally (e.g. pass it to some virt tool) > >> you > >> probably want to prepare the image and get the path to the image on the > >> host > >> from the results of Image.prepare(). In this case you are responsible for > >> tearing > >> down the image. This how image transfer prepare and teardown images. > >> > >> > >>> The specialty of ISO image is > >>> that it makes sense to have it attached to multiple VMs. > >> > >> > >> There should be no issue to share ISO image as read only image. > >> > >> > >>> And that also > >>> means something should control whether image needs attaching or whether > >>> the image is already attached to the host. > >> > >> > >> All images need to be prepared and teardown. You should not care about the > >> type. > >> Vdsm will do the right thing. > >> > >> > >>> Similarly the image should be > >>> (attempted to) detached only when there is no longer any VM on the host > >>> that uses it. > >>> > >> > >> Usually engine is responsible for preparing and tearing down images. I know > >> we > >> have some holes in this are
[ovirt-devel] Re: Access to images in block domain from more VMs
On Thu, 4 Jul 2019 23:59:07 +0300 Nir Soffer wrote: > On Tue, Jul 2, 2019 at 1:41 PM Tomáš Golembiovský > wrote: > > > Hi, > > > > we have a large gap in handling ISO files in data domains and especially > > on block domains. None of the flows that work with ISOs works (well, one > > sort of does): > > > > 1) Change CD for running VM [1] > > > > Broken because VM.changeCD accepts a path instead of PDIV. > > This used to work with ISO domain since file based storage does not need > to be prepared, but with block storage someone must prepare the ISO image > before using it and tear down the image when done. > > If you send PDIV to vdsm vdsm will prepare the image and tear it down > and use the correct path to the image. > > > > 2) Attaching boot disk in Run Once -- this works but I wonder if it's by > >accident, because engine issues spurious teardown on images [2] > > > > Can you point to more info about "spurious teardown"? See the linked bug [2]. When you configure same ISO to two VMs on the same host, engine tries to teardown the image after first VM is powered off while second VM is still using it. It is similar to the upload-flow you described below. > > > 3) Guest tools during VM import [3] > > > > Looks like [2] and [3] are the same. We don't know what > "Guest tools during VM import" means. When importing a VM user has an option to pick ISO with Windows drivers. The drivers will be injected into the VM during import. Same as 1) this relied on the fact that paths to ISO domain don't change and passed the path in API. > > > 4) Automatic attach of guest tools to Windows VMs > > > > I don't have any idea what is this automatic attach. Engine automatically picks guest tools ISO and adds it to the VM definition for you when you start Windows guest with old guest tools. Our main problem here is not related to prepare/teardown. We didn't get that far yet. :) Right now the issue is that the ISOs in data domains are not checked when searching for the latest ISO. > > Before virt can fix all those we need input from storage on how we > > should handle the images on block domains. > > > You should handle ISO images in the same way for all domains: > - never assume any path on the host, you should not care about the path, > and it is different for iso/data file/data block. > - If you start a vm with a ISO, or plug/unplug, always use PDIV and let vdsm > prepare and teardown the image for you, and update the xml with the > correct > path > - if you need to access the ISO externally (e.g. pass it to some virt tool) > you > probably want to prepare the image and get the path to the image on the > host > from the results of Image.prepare(). In this case you are responsible for > tearing > down the image. This how image transfer prepare and teardown images. > > > > The specialty of ISO image is > > that it makes sense to have it attached to multiple VMs. > > > There should be no issue to share ISO image as read only image. > > > > And that also > > means something should control whether image needs attaching or whether > > the image is already attached to the host. > > > All images need to be prepared and teardown. You should not care about the > type. > Vdsm will do the right thing. > > > > Similarly the image should be > > (attempted to) detached only when there is no longer any VM on the host > > that uses it. > > > > Usually engine is responsible for preparing and tearing down images. I know > we > have some holes in this area. > > Hence my question to storage -- is there already some framework from > > storage for handling this? Does it make more sense to do this on engine > > side or should each host handle it on it's own? > > > We considered moving management of prepared images to vdsm, in the same > way it handles managed block storage, but there are no concrete plans yet. > > > To me it seems > > preferable to handle this on engine side as that is where the requests > > for attach/detach normally come from (disks in VM import are an > > exception). It could possibly mean less race conditions (but I may be > > totally wrong here). Also having it on VDSM side would probably mean > > changes to the API for 1) and 2). > > > The issue is not where request to prepare and teardown come from, but > conflicting requests. For example: > > - Flow 1 prepare volume V1, V2, V3 > - Flow 1 start to download volume V3 > - Flow 2 prepare volumes V1, V2 > - Flow 2 start to download v
[ovirt-devel] Access to images in block domain from more VMs
Hi, we have a large gap in handling ISO files in data domains and especially on block domains. None of the flows that work with ISOs works (well, one sort of does): 1) Change CD for running VM [1] 2) Attaching boot disk in Run Once -- this works but I wonder if it's by accident, because engine issues spurious teardown on images [2] 3) Guest tools during VM import [3] 4) Automatic attach of guest tools to Windows VMs Before virt can fix all those we need input from storage on how we should handle the images on block domains. The specialty of ISO image is that it makes sense to have it attached to multiple VMs. And that also means something should control whether image needs attaching or whether the image is already attached to the host. Similarly the image should be (attempted to) detached only when there is no longer any VM on the host that uses it. Hence my question to storage -- is there already some framework from storage for handling this? Does it make more sense to do this on engine side or should each host handle it on it's own? To me it seems preferable to handle this on engine side as that is where the requests for attach/detach normally come from (disks in VM import are an exception). It could possibly mean less race conditions (but I may be totally wrong here). Also having it on VDSM side would probably mean changes to the API for 1) and 2). Any input appreciated. Tomas [1] https://bugzilla.redhat.com/show_bug.cgi?id=1589763 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1721455 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1721455 -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GCHBJ6YSDWHBYA3JTRJDKQZ4CBQ7IUIU/
[ovirt-devel] Re: VDSM and safelease
On Fri, 5 Apr 2019 10:58:43 +0200 Tomáš Golembiovský wrote: > On Tue, 2 Apr 2019 19:14:12 +0300 > Nir Soffer wrote: > > > On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg wrote: > > > > > On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer wrote: > > > > > >> I think it is time to remove export and iso domain in 4.4. > > >> > > > > > > Would it be possible? > > > If an ovirt-4.3 storage pool has an ISO domain, and we add an ovirt-4.4 > > > host to it, we would like it to be able to become SPM. > > > > > > > In rhel 8.1, vdsm 4.4, I don't want to support export or iso domain > > regardless of the > > cluster version. > > > > We don't have the time to port all code in vdsm to python 3. If you want > > python 3, you need > > to remove some features. > > > > If you want to mix 4.4. host with 4.3, env, detach the iso domain and > > export domain? > > > > Well, I'm not strictly opposed to that, but let me ask... will we have a > programatic way of attaching an ISO to a host usable from external > tools? > > In IMS project we rely on guest tools ISO in ISO domain and we already > have a request to support ISOs from data domains. But last time I've > heard using vdsm-client to call Image.prepare and Image.tearDown is not > strictly "supported" API. And obviously this has to be possible to do from two hosts at the same time for concurrent conversions. > > Please excuse my ignorance if there is already some other way to do > that. > > Tomas > > > -- > Tomáš Golembiovský -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/A4E76UJ5BEKQMNA7GCNGZ6AWLG35VMAR/
[ovirt-devel] Re: VDSM and safelease
On Tue, 2 Apr 2019 19:14:12 +0300 Nir Soffer wrote: > On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg wrote: > > > On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer wrote: > > > >> I think it is time to remove export and iso domain in 4.4. > >> > > > > Would it be possible? > > If an ovirt-4.3 storage pool has an ISO domain, and we add an ovirt-4.4 > > host to it, we would like it to be able to become SPM. > > > > In rhel 8.1, vdsm 4.4, I don't want to support export or iso domain > regardless of the > cluster version. > > We don't have the time to port all code in vdsm to python 3. If you want > python 3, you need > to remove some features. > > If you want to mix 4.4. host with 4.3, env, detach the iso domain and > export domain? > Well, I'm not strictly opposed to that, but let me ask... will we have a programatic way of attaching an ISO to a host usable from external tools? In IMS project we rely on guest tools ISO in ISO domain and we already have a request to support ISOs from data domains. But last time I've heard using vdsm-client to call Image.prepare and Image.tearDown is not strictly "supported" API. Please excuse my ignorance if there is already some other way to do that. Tomas -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/75UUTOXB443BO3MF4MC5BQLYH47PGVLI/
[ovirt-devel] Re: SSO with lightdm
Hi, On Mon, 17 Dec 2018 14:40:22 +0100 Sandro Bonazzola wrote: > Il giorno lun 17 dic 2018 alle ore 07:09 ha scritto: > > > I knows there are the GDM plugin and KDM plugin of ovirt-guest-agent that > > makes SSO in linux is possible. > > > > I want to make SSO with lightdm is possble. To add lightdm plugin to > > ovirt-guest-agent is enough? or something more is needed? > > > > I don't know how to develop SSO with lightdm. > > > > Adding Tomas. I would suggest to open a bug tracking this RFE and explain > the use case to motivate the request. > Actually we are in the process of sun-setting the oVirt Guest Agent and we don't add new features. We have moved the most important features into QEMU Guest Agent. However, SSO is not one of them and we don't have a plan how or even if we're going to do that. There is minimal demand for this. Of course, if you're brave enough to implement the feature in oVirt Guest Agent I can include that. Tomas > > > > > > > > > > ___ > > Devel mailing list -- devel@ovirt.org > > To unsubscribe send an email to devel-le...@ovirt.org > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > > oVirt Code of Conduct: > > https://www.ovirt.org/community/about/community-guidelines/ > > List Archives: > > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WZ5BH5MRWZYNQCJRUJ6LDXUSFFBUKOFB/ > > > > > -- > > SANDRO BONAZZOLA > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA <https://www.redhat.com/> > > sbona...@redhat.com > <https://red.ht/sig> -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/QB2FKHRWHBU3WJFK6D6Z4IR2GR7KW7PK/
[ovirt-devel] Re: [ovirt-devel] ovirt-guest-agent_master_build-artifacts-fc28-x86_64 Fails to Build
We hit this one before. It was an issue with tooling, but I cannot remember what exactly that was. Bad pywin32 version maybe? Sandro, do you remember? Tomas On Fri, 31 Aug 2018 13:52:06 +0200 Anton Marchukov wrote: > Hello All. > > Looks like ovirt-guest-agent_master_build-artifacts-fc28-x86_64 nolonger > works, as I see it fails to build with the following error: > > *10:53:41* 0009:fixme:module:find_dll_file skipping > L"C:\\windows\\system32\\dbghelp.dll" because of wrong > architecture*10:53:42* 004a:err:msiexec:custom_action_server Failed to > create custom action server pipe: 2 > > > than it fails to recognize that and the whole job fails on a time out: > > *16:41:14* Build timed out (after 360 minutes). Marking the build as failed. > > > As a result, OST for guest-agent also fails. I tried to rerun the job and > got the same problem. > > The failing job is at [1] and I also opened JIRA issue [2] to track it. > > [1] > http://jenkins.ovirt.org/job/ovirt-guest-agent_master_build-artifacts-fc28-x86_64/4 > [2] https://ovirt-jira.atlassian.net/browse/OVIRT-2466 > > -- > Anton Marchukov > Team Lead - Release Management - RHV DevOps - Red Hat -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FLDR75UHFYBTMJQ2SBYNCS4XOXMAALBZ/
[ovirt-devel] Re: ovirt extensions -- weekly report
Hi, On Sun, 24 Jun 2018 11:44:37 -0400 Greg Sheremeta wrote: > ovirt extensions -- weekly report > > Hi, > > Note: A team is working on a feature to make ansible roles/playbooks > runnable via the administration portal. This is the first edition of my > weekly status report on the project. > > Note2: if you cannot access a document, please let me know. I will be > converting them all away from google docs so they are public by default. > > project book: ovirt extensions project book [1] > trello: none (yet - ?) > > The project has 3 sub-parts, currently: > migrate-vm > cluster-upgrade > central considerations (long-running operations, APIs, notifications) > > *migrate-vm* > design document: [2] > design discussion moved to github: [3] > patches: [4] > Status: Design complete (comments welcome though!) UI patch posted and *in > code review*. > Action items > * *Greg, Tomas, Scott*: code review > > *cluster-upgrade* > design document: [5] > design discussion moved to github: PR [6] > Status: *in design review.* Please comment freely on the PR! > Action items: > * *all* - design review > * *Greg*: code UI (haven't begun) > > *central considerations* > design document: [7] > design discussions on github: [8] > patches: [9] > Status: *in coding (notifications + API)* > Action items: > * *Greg*: coding notifications drawer > * *Ondra*: coding ansible remote API > > > [1] ovirt extensions project book - Google Docs > https://docs.google.com/document/d/1n4VlosdPnIZL81wx0sEIrkAfBehuV5DfOU7eH9isWT0/edit > > [2] Migrate VMs Modal - Google Docs > https://docs.google.com/document/d/1NF46ZJSOcGFrLWx18Ujsckoob19ANfBlpisB6_fk-WU/edit > > [3] ovirt-design - Migrate Virtual Machines > https://ovirt.github.io/ovirt-design/admin-ui/compute/migrate-vms > > [4] topic:vm-migrate | gerrit.ovirt Code Review > https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine-dashboard+branch:master+topic:vm-migrate > > [5] Cluster Upgrade - Google Docs > https://docs.google.com/document/d/1kRDAeu0-wIKbSNieXenQY5qevwNlyCnpyZdeUX-LWQw/edit > > [6] Adding design proposal around Upgrading a Cluster by lizsurette · Pull > Request #5 · oVirt/ovirt-design > https://github.com/oVirt/ovirt-design/pull/5 > > [7] ovirt-engine-ui-extensions - overall design considerations and notes - > Google Docs > https://docs.google.com/document/d/1GMurjSMtzLaZFktH_Ysge4lRIpLd0nosuV1m8IRL6lY/edit > > [8] ovirt-design/notifications.md at master · oVirt/ovirt-design > https://github.com/oVirt/ovirt-design/blob/master/admin-ui/framework/notifications.md > > [9] Change I73f35974: [WIP!!] webadmin: notifications drawer | gerrit.ovirt > Code Review > https://gerrit.ovirt.org/#/c/92443/ > > Change Ib7198f91: services: Add /ansible service for remote execution | > gerrit.ovirt Code Review > https://gerrit.ovirt.org/#/c/92404/ I am unable to access this one. Gerrit says: The page you requested was not found, or you do not have permission to view this page. Tomas > > Best wishes, > Greg > > -- > > GREG SHEREMETA > > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > > Red Hat NA > > <https://www.redhat.com/> > > gsher...@redhat.comIRC: gshereme > <https://red.ht/sig> -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2TJNNJQEU45RIUM763UEK266NVPHK6EP/
[ovirt-devel] CI not responding to GitHub web hooks
Hi, it seems CI is not responding to GitHub web hooks... is it congested or broken? Tomas -- Tomáš Golembiovský ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/SGV223RQJLXJQUFUKANGQMTVO4ITZZOR/
Re: [ovirt-devel] ovirt-host-deploy and python3
On Fri, 4 May 2018 09:33:11 +0200
Sandro Bonazzola wrote:
> 2018-05-03 21:58 GMT+02:00 Tomáš Golembiovský :
>
> > Hi,
> >
> > I'm trying to reinstall a CentOS host (using master-snapshot) and I
> > noticed otopi is trying to use python3 while the ovirt-host-deploy is
> > not yet fully python3 compatible:
> >
>
> How did you got python 3 on CentOS?
> It's not in CentOS distribution.
From EPEL. We have 'python34*' listed in our ovirt-*-epel repos.
Tomas
>
> >
> >
> > > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:39 SYSTEM INFORMATION - BEGIN
> > > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:40 executable /bin/python3
> > > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:41 python version 3.4.8 (default, Mar 23 2018, 10:04:27)
> > > [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
> > > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:42 python /bin/python3
> > > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:43 platform linux
> > > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:44 distribution ('CentOS Linux', '7.4.1708', 'Core')
> > > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:45 host 'ovirt-host2'
> > > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:51 uid 0 euid 0 gid 0 egid 0
> > > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> > info._init:53 SYSTEM INFORMATION - END
> >
> > and then later:
> >
> > > 2018-05-03 21:35:56,912+0200 DEBUG otopi.context
> > context._executeMethod:128 Stage init METHOD otopi.plugins.ovirt_host_
> > deploy.node.detect.Plugin._init
> > > 2018-05-03 21:35:56,914+0200 DEBUG otopi.context
> > context._executeMethod:143 method exception
> > > Traceback (most recent call last):
> > > File "/tmp/ovirt-a0GNITSwX9/pythonlib/otopi/context.py", line 133, in
> > _executeMethod
> > > method['method']()
> > > File
> > > "/tmp/ovirt-a0GNITSwX9/otopi-plugins/ovirt-host-deploy/node/detect.py",
> > line 131, in _init
> > > odeploycons.FileLocations.OVIRT_NODE_VARIANT_VAL)
> > > File
> > > "/tmp/ovirt-a0GNITSwX9/otopi-plugins/ovirt-host-deploy/node/detect.py",
> > line 69, in hasconf
> > > io.StringIO('[default]\n' + f.read().decode('utf-8'))
> > > AttributeError: 'str' object has no attribute 'decode'
> > > 2018-05-03 21:35:56,915+0200 ERROR otopi.context
> > context._executeMethod:152 Failed to execute stage 'Initializing': 'str'
> > object has no attribute 'decode'
> >
> > There is definitely a bug (or at least weirdness) in host-deploy -- why
> > use .decode() on object returned by codecs.open()?
> >
> > But also, should host-deploy be already python3 compatible and is this
> > otopi behaviour expected?
> >
> > Tomas
> >
> >
> > --
> > Tomáš Golembiovský
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://red.ht/sig>
> <https://redhat.com/summit>
--
Tomáš Golembiovský
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] ovirt-host-deploy and python3
Hi,
I'm trying to reinstall a CentOS host (using master-snapshot) and I
noticed otopi is trying to use python3 while the ovirt-host-deploy is
not yet fully python3 compatible:
> 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:39 SYSTEM INFORMATION - BEGIN
> 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:40 executable /bin/python3
> 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:41 python version 3.4.8 (default, Mar 23 2018, 10:04:27)
> [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
> 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:42 python /bin/python3
> 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:43 platform linux
> 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:44 distribution ('CentOS Linux', '7.4.1708', 'Core')
> 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:45 host 'ovirt-host2'
> 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:51 uid 0 euid 0 gid 0 egid 0
> 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info
> info._init:53 SYSTEM INFORMATION - END
and then later:
> 2018-05-03 21:35:56,912+0200 DEBUG otopi.context context._executeMethod:128
> Stage init METHOD otopi.plugins.ovirt_host_deploy.node.detect.Plugin._init
> 2018-05-03 21:35:56,914+0200 DEBUG otopi.context context._executeMethod:143
> method exception
> Traceback (most recent call last):
> File "/tmp/ovirt-a0GNITSwX9/pythonlib/otopi/context.py", line 133, in
> _executeMethod
> method['method']()
> File
> "/tmp/ovirt-a0GNITSwX9/otopi-plugins/ovirt-host-deploy/node/detect.py", line
> 131, in _init
> odeploycons.FileLocations.OVIRT_NODE_VARIANT_VAL)
> File
> "/tmp/ovirt-a0GNITSwX9/otopi-plugins/ovirt-host-deploy/node/detect.py", line
> 69, in hasconf
> io.StringIO('[default]\n' + f.read().decode('utf-8'))
> AttributeError: 'str' object has no attribute 'decode'
> 2018-05-03 21:35:56,915+0200 ERROR otopi.context context._executeMethod:152
> Failed to execute stage 'Initializing': 'str' object has no attribute 'decode'
There is definitely a bug (or at least weirdness) in host-deploy -- why
use .decode() on object returned by codecs.open()?
But also, should host-deploy be already python3 compatible and is this
otopi behaviour expected?
Tomas
--
Tomáš Golembiovský
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Unremovable disks created through the API
On Wed, 7 Mar 2018 15:12:58 +0200 Arik Hadas wrote: > On Wed, Mar 7, 2018 at 1:01 PM, Tomáš Golembiovský > wrote: > > > Hi, > > > > this sounds like a good idea in general. Few interconnected questions > > though... > > > > On Wed, 7 Mar 2018 10:42:31 +0200 > > Arik Hadas wrote: > > > > > IMHO, the process should be comprised of: > > > 1. virt-v2v calls an API with the (probably partial since the OS and > > other > > > things are unknown at that point) OVF configuration > > > 2. virt-v2v uploads the disks > > > 3. virt-v2v provides the up-to-date configuration > > > > > > Step #1 will enable ovirt-engine: > > > 1. Most importantly, to cleanup uploaded disks in case of an error during > > > the import process. Otherwise, we require the client to clean them up, > > > which can be challenging (e.g., if the virt-v2v process crashes). > > > > Who will handle the removal in case of problems? Engine after timeout? > > Or is the only benefit that administrator can remove all disks in one > > step by removing the VM? > > > > So I was thinking that the wrapper command will hold the amount of disks > that should be uploaded for the VM. > If for some predefined period of time no new disk is added or an upload > doesn't make any progress (assuming the uploads are done sequentially), to > fail the import operation and that would roll back the resources (disks, > VMs) that were created as part of the import process. > > > > > > Note that the uploads do not timeout at the moment. However strange that > > might be. So I assume removing the disks/VM will be impossible anyway > > because of locking. > > > > Yeah, I think no timeout was defined because uploading from the browser is > relatively fragile and we didn't want the upload to fail, and the partial > disks to be removed, due to browser issues but rather to be able to resume > their upload. But different logic can be implemented in the wrapping > command. Would it make sense to add the timeout parameter to API? That way the client can choose whether it wants one and how big. No timeout could still be the default. Tomas > As for locking, we don't have to call RemoveDisk but instead, to terminate > the upload which will eventually remove the disks. > > > > > > > > > 2. To inform the user that the process has started - so he won't get > > > surprised by seeing disks being uploaded suddenly. That will give a > > context > > > to these upload operations. > > > > The uploaded disks will still remain unattached though. Or do you plan > > for Engine to create and attach the disks? > > > > Right, so when we have that "context" and a VM entity in the databse, we > can attach the disks to the VM when they are created. > > > > > > > > > 3. To inform the user about the progress of the import process, much like > > > we do today when importing VMs from vSphere to RHV. > > > > How will this be handled? Will Engine report the progress in the Virtual > > Machines view and compute something based on the upload progress? > > > > Yes, I don't see why not showing that in the status field (at the VMs tab) > as we do today for VMs that are being imported. > The engine would need to know the estimated actual sizes of the disks in > order to compute it though. > > > > > > Tomas > > > > > 4. To perform validations on the (partial) VM configuration, e.g., > > > verifying that no VM with the same name exists/verifying there is enough > > > space (optionally mapping different disks to different storage devices) > > and > > > so on, before uploading the disks. > > > > > > > > > The gaps I see: > > > 1. We don't have a command for step #1 yet but that's something we can > > > provide relatively quickly. We need it also to support uploading an OVA > > via > > > oVirt's webadmin. > > > 2. We have a command for step #3, but it is not exposed via the API. > > > > > > -- > > Tomáš Golembiovský > > -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Unremovable disks created through the API
Hi, this sounds like a good idea in general. Few interconnected questions though... On Wed, 7 Mar 2018 10:42:31 +0200 Arik Hadas wrote: > IMHO, the process should be comprised of: > 1. virt-v2v calls an API with the (probably partial since the OS and other > things are unknown at that point) OVF configuration > 2. virt-v2v uploads the disks > 3. virt-v2v provides the up-to-date configuration > > Step #1 will enable ovirt-engine: > 1. Most importantly, to cleanup uploaded disks in case of an error during > the import process. Otherwise, we require the client to clean them up, > which can be challenging (e.g., if the virt-v2v process crashes). Who will handle the removal in case of problems? Engine after timeout? Or is the only benefit that administrator can remove all disks in one step by removing the VM? Note that the uploads do not timeout at the moment. However strange that might be. So I assume removing the disks/VM will be impossible anyway because of locking. > 2. To inform the user that the process has started - so he won't get > surprised by seeing disks being uploaded suddenly. That will give a context > to these upload operations. The uploaded disks will still remain unattached though. Or do you plan for Engine to create and attach the disks? > 3. To inform the user about the progress of the import process, much like > we do today when importing VMs from vSphere to RHV. How will this be handled? Will Engine report the progress in the Virtual Machines view and compute something based on the upload progress? Tomas > 4. To perform validations on the (partial) VM configuration, e.g., > verifying that no VM with the same name exists/verifying there is enough > space (optionally mapping different disks to different storage devices) and > so on, before uploading the disks. > > > The gaps I see: > 1. We don't have a command for step #1 yet but that's something we can > provide relatively quickly. We need it also to support uploading an OVA via > oVirt's webadmin. > 2. We have a command for step #3, but it is not exposed via the API. -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Packages for Python SDK
On Mon, 12 Feb 2018 15:31:22 + "Richard W.M. Jones" wrote: > On Mon, Feb 12, 2018 at 02:26:09PM +0100, Tomáš Golembiovský wrote: > > Hi, > > > > are there any plans to have the packages for Python SDK in base > > repositories of CentOS and Fedora? They seem to be available only from > > oVirt and Virt SIG repos. > > > > I saw that Juan used to build the v3 packages for Fedora. > > > > The rationale behind is that virt-v2v is considering to add support for > > the disk upload API and would like to use Python snippets so as not to > > re-implement the calls in curl. > > Also where is the source RPM for python3-ovirt-engine-sdk4? > > I got the python 2 package (python-ovirt-engine-sdk4) to rebuild on > Fedora starting from the CentOS source RPM found here: > > http://resources.ovirt.org/pub/ovirt-4.2/rpm/el7Server/SRPMS/ > > but I couldn't find the source RPM for the python3 package. Here: http://resources.ovirt.org/pub/ovirt-4.2-snapshot/rpm/fc27/SRPMS/python-ovirt-engine-sdk4-4.2.4-1.20180209gita93f0f2.fc27.src.rpm Tomas > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.org -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Packages for Python SDK
Hi, are there any plans to have the packages for Python SDK in base repositories of CentOS and Fedora? They seem to be available only from oVirt and Virt SIG repos. I saw that Juan used to build the v3 packages for Fedora. The rationale behind is that virt-v2v is considering to add support for the disk upload API and would like to use Python snippets so as not to re-implement the calls in curl. Tomas -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] oVirt Guest Agent maintainer
Hi,
I don't remember if this was properly announced before so here it goes.
Some of you already know that.
I've been maintaining the ovirt-guest-agent related things for about
half a year (Vinzenz Feenstra is no longer with us). Recently I've been
also granted merge rights to the project on Gerrit. You may still find
Vinzenz's name mentioned on lots of places, but if you need anything GA
related you should contact me and not him.
Cheers,
Tomas
--
Tomáš Golembiovský
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [rhevm-staff] oVirt website hackathon
On Sun, 24 Sep 2017 17:51:50 +0300 Eyal Edri wrote: > On Sun, Sep 24, 2017 at 4:52 PM, Eyal Edri wrote: > > > > > On Sun, Sep 24, 2017 at 4:48 PM, Eyal Edri wrote: > > > >> Hi, > >> > >> So I've found linkchecker[1], which is quite a powerful and useful tool > >> for that, and run it on oVirt.org, the results are not good, unfortunately. > >> We have over 15K(!) of broken links to fix before we can even consider > >> adding a constant CI job to check new commits. How about checking that no *new* broken links are introduced by pull requests? Would that be easy enough to do? > >> > >> Snippet example from the huge report attached to this email [2]. ( btw > >> there are other formats available to generate this report if we want ) > >> > > > > resending with zipped report ( the file was 16MB, too big for the list ). > > > > I've rerun the tool excluding .png images, since there are many of them and > the broken links got down to 2373, to much more reasonable number > to start working on. 2k is "reasonable"? Really? :) > Attached new report w/o images. > > > > > > > >> > >> After we'll do an initial cleanup of the broken links ( similar to what > >> we did on findbugs errors ), we can consider adding CI for it, 2 ideas I > >> had in mind: > >> > >> > >> 1. Running the tool on GitHub PR using Travis CI ( which ovirt-site is > >> already connected to it ), the tool seems to be using it as well for > >> testing itself > >> 2. Adding ovirt-site as a std-ci project and using it to also properly > >> deploy to the site in the end ( more complex and long term goal, which > >> might require more work ). > >> > >> > >> TL;DR, let's schedule a doc-fix day first to address the sheer amount of > >> broken links and then worry about adding CI. > >> > >> > >> > >> [1] https://github.com/wummel/linkchecker > >> [2] > >> > >> URL `develop/release-management/features/sla/hosted-engine-agent > >> -offloading/#documentation' > >> Name `Documentation/External references' > >> Parent URL https://ovirt.org/develop/release-management/features/sla/ > >> hosted-engine-agent-offloading/, line 1870, col 131 (HTML > >> <http://validator.w3.org/check?ss=1&uri=https://ovirt.org/develop/release-management/features/sla/hosted-engine-agent-offloading/>) > >> (CSS > >> <http://jigsaw.w3.org/css-validator/validator?uri=https://ovirt.org/develop/release-management/features/sla/hosted-engine-agent-offloading/&warning=1&profile=css2&usermedium=all> > >> ) > >> Real URL https://ovirt.org/develop/release-management/features/sla/ > >> hosted-engine-agent-offloading/develop/release-management/ > >> features/sla/hosted-engine-agent-offloading/#documentation > >> Size 14.63KB > >> Check time 3.496 seconds > >> Result Error: 404 Not Found > >> > >> > >> URL `/images/apple-touch-icon-precomposed.png' > >> Parent URL https://www.ovirt.org, line 22, col 1 (HTML > >> <http://validator.w3.org/check?ss=1&uri=https://www.ovirt.org>) (CSS > >> <http://jigsaw.w3.org/css-validator/validator?uri=https://www.ovirt.org&warning=1&profile=css2&usermedium=all> > >> ) > >> Real URL https://www.ovirt.org/images/apple-touch-icon-precomposed.png > >> Size 14.63KB > >> Check time 1.851 seconds > >> Result Error: 404 Not Found > >> > >> > > > > -- > > > > 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 <+972%209-769-2018> > > irc: eedri (on #tlv #rhev-dev #rhev-integ) > > > > > > -- > > 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) -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Memory stats in VDSM
Hi, there is ongoing effort to change how VDSM collects information about memory usage from guests. We used to use oVirt guest agent to get the statistics about free memory, swap usage, etc. This is going to change and we will use stats provided by VirtIO Balloon driver. [1] This should not break MOM nor Engine (current or previous versions). There is however small downside to this change. We will not be able to fetch information about buffers and caches on Linux guests anymore (mem_cached and mem_buffers in memoryStats). The corollary of this is that free memory reported by Engine will also no longer include those statistics and reported free memory will be really (only) free memory. I now there will be mixed feelings about this and we would like to get the information about buffers and caches back to the VDSM. Correctly via balloon driver statistics. [2] This effort will however take some time. Tomas [1] https://gerrit.ovirt.org/#/q/topic:memory-stats [2] https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05239.html -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Please join the oVirt team @ GitHub
On Thu, 24 Aug 2017 09:40:01 +0300 Barak Korren wrote: > Please post all these requests as comments to the tracker ticket: > https://ovirt-jira.atlassian.net/browse/OVIRT-1608 > > Also, if you can request to join the org from inside GitHub please do so, > AFAIK until you do we can actually just send invites, not actually join you. Actually I think it works the other way around. You send invites to other people to join your Organization. https://help.github.com/articles/inviting-users-to-join-your-organization/ Tomas > > On 24 August 2017 at 04:54, Marc Young <3vilpeng...@gmail.com> wrote: > > > Can I get added as well? > > > > On Wed, Aug 23, 2017 at 12:21 PM, Nir Soffer wrote: > > > >> Seems that one screenshot is missing: > >> > >> [image: Screenshot from 2017-08-23 20-01-06.png] > >> > >> > >> On Wed, Aug 23, 2017 at 8:19 PM Nir Soffer wrote: > >> > >>> Adding is nice but not enough, you should make sure you are added as > >>> "public". > >>> > >>> Currently about of the people on ovirt are private. To see the issue. > >>> When I'm logged > >>> in, oVirt has 80 members, after logging out, only 37: > >>> > >>> [image: Screenshot from 2017-08-23 20-00-41.png][image: Screenshot from > >>> 2017-08-23 20-01-06.png] > >>> > >>> Also having a real picture on github is a good idea. > >>> > >>> Nir > >>> > >>> On Wed, Aug 23, 2017 at 7:05 PM Sharon Gratch > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> Can you please add me (sgratch) too? > >>>> > >>>> Thanks > >>>> > >>>> On Wed, Aug 23, 2017 at 12:12 PM, Eyal Edri wrote: > >>>> > >>>>> I think only admins of the oVirt org on GitHub can add new members, > >>>>> opening a ticket to collect all requests. > >>>>> > >>>>> On Wed, Aug 23, 2017 at 12:04 PM, Shmuel Melamud > >>>>> wrote: > >>>>> > >>>>>> Can you add me (smelamud) too? > >>>>>> > >>>>>> On Wed, Aug 23, 2017 at 11:38 AM, Martin Perina > >>>>>> wrote: > >>>>>> > > >>>>>> > > >>>>>> > On Wed, Aug 23, 2017 at 10:29 AM, Denis Chaplygin < > >>>>>> dchap...@redhat.com> > >>>>>> > wrote: > >>>>>> >> > >>>>>> >> Hello! > >>>>>> >> > >>>>>> >> On Wed, Aug 23, 2017 at 10:21 AM, Yaniv Kaul > >>>>>> wrote: > >>>>>> >>> > >>>>>> >>> Please join at[1]. > >>>>>> >>> As the team uses more and more projects at GitHub, it makes it's > >>>>>> easier > >>>>>> >>> to find the nicknames if you are registered. > >>>>>> >>> > >>>>>> >> > >>>>>> >> How can i join? There is no 'join' or 'apply' links. > >>>>>> > > >>>>>> > > >>>>>> > Adding Eyal, I remember that initially this list was manually > >>>>>> created by our > >>>>>> > CI team ... > >>>>>> > > >>>>>> >> > >>>>>> >> > >>>>>> >> ___ > >>>>>> >> Devel mailing list > >>>>>> >> Devel@ovirt.org > >>>>>> >> http://lists.ovirt.org/mailman/listinfo/devel > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > ___ > >>>>>> > Devel mailing list > >>>>>> > Devel@ovirt.org > >>>>>> > http://lists.ovirt.org/mailman/listinfo/devel > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> 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 <+972%209-769-2018> > >>>>> irc: eedri (on #tlv #rhev-dev #rhev-integ) > >>>>> > >>>>> ___ > >>>>> Devel mailing list > >>>>> Devel@ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/devel > >>>>> > >>>> > >>>> ___ > >>>> Devel mailing list > >>>> Devel@ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/devel > >>> > >>> > >> ___ > >> Devel mailing list > >> Devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/devel > >> > > > > > > ___ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > -- > Barak Korren > RHV DevOps team , RHCE, RHCi > Red Hat EMEA > redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM] testV2VOutput (v2vTests.v2vTests) failing in jenkins
argv)\nelapsed_time = 0\n\n\ndef
> > write_output(msg):\nsys.stdout.write(msg)\n
> > sys.stdout.flush()\n\ndef write_trace(msg):\n
> > sys.stderr.write(msg)\nsys.stderr.flush()\n\ndef
> > write_progress():\nglobal elapsed_time\nfor i in range(101):\n
> >write_output(\'(%s/100%%)\\r\' % str(i))\n
> > elapsed_time = elapsed_time + 1\n\nwrite_output(\'[ %d.0] Opening
> > the source -i libvirt\\n\' % elapsed_time)\nelapsed_time =
> > elapsed_time + 1\nwrite_output(\'[ %d.0] Creating an overlay to
> > protect\\n\' % elapsed_time)\nelapsed_time = elapsed_time + 1\n\nif
> > options.libguestfsTrace:\nwrite_trace("libguestfs: trace:
> > internal_autosync = 0\\n")\nwrite_trace("libguestfs: sending
> > SIGTERM to process 12345\\n")\nwrite_trace("libguestfs: trace:
> > shutdown = 0\\n")\nwrite_trace("libguestfs: trace: close\\n")\n
> > write_trace("libguestfs: closing guestfs handle 0x1e265f0 (state
> > 0)\\n")\n\nfor i, o in enumerate(options.vdsmImageId):\n
> > write_output(\'[ %d.0] Copying disk %d/2 to %s/%s/images/%s\\n\' %\n
> >(elapsed_time, i+1, options.outputStorage,\n
> > options.vdsmVmId, o))\n\n# Immitate some verbose messages\n
> > # NOTE: Most verbose messages go to stderr, but some go to stdout.
> > This can\n# potentialy mess with our parsing routine.\nif
> > options.verbose:\nwrite_output("target_file = %s\\n" %
> > options.vdsmVolId[i])\nwrite_output("target_format =
> > raw\\n")\nwrite_output("target_estimated_size =
> > 123456789\\n")\nwrite_output("target_overlay =
> > /var/tmp/v2vovl344e53.qcow2\\n")\n\nwrite_progress()\n
> > write_output(\'[ %d.0] Creating output metadata\\n\' % elapsed_time)\n
> >write_output(\'[ %d.0] Finishing off\\n\' % elapsed_time)\n'
> > 21:08:48 >> begin captured logging <<
> >
> > 21:08:48 2016-12-17 21:08:08,445 DEBUG (MainThread) [root]
> > /usr/bin/taskset --cpu-list 0-15
> > /home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/fake-virt-v2v
> > -v -x -ic 'vpx://adminr%40vsphere@0.0.0.0/ovirt/0.0.0.0?no_verify=1'
> > -o vdsm -of raw -oa sparse --vdsm-image-uuid
> > ----0001 --vdsm-vol-uuid
> > ----0002 --vdsm-image-uuid
> > ----0003 --vdsm-vol-uuid
> > ----0004 --password-file /tmp/mypass
> > --vdsm-vm-uuid ----0005 --vdsm-ovf-output
> > /usr/local/var/run/vdsm/v2v --machine-readable -os
> > /rhev/data-center/----0006/----0007
> > TEST (cwd None) (commands:69)
> > 21:08:48 2016-12-17 21:08:08,496 DEBUG (MainThread) [root] SUCCESS:
> > = 'libguestfs: trace: internal_autosync = 0\nlibguestfs: sending
> > SIGTERM to process 12345\nlibguestfs: trace: shutdown = 0\nlibguestfs:
> > trace: close\nlibguestfs: closing guestfs handle 0x1e265f0 (state
> > 0)\n'; = 0 (commands:93)
> > 21:08:48 - >> end captured logging <<
> > -
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
--
Tomáš Golembiovský
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Gerrit headers are not added to commits in vdsm repo
Hi, I've noticed that in vdsm repo the merged commits do not contain the info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.). Is that intentional? If yes, what was the motivation behind this? The change seem to have happened about 4 days ago. Sometime between the following two commits: * 505f5da API: Introduce getQemuImageInfo API. [Maor Lipchuk] * 1c4a39c protocoldetector: Avoid unneeded getpeername() [Nir Soffer] Thanks, Tomas -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Thu, 28 Jul 2016 13:28:42 +0200 Tomáš Golembiovský wrote: > On Thu, 21 Jul 2016 08:24:57 -0400 (EDT) > Francesco Romani wrote: > > > - Original Message - > > > From: "Nir Soffer" > > > To: "Tomáš Golembiovský" > > > Cc: "Francesco Romani" , "devel" , > > > "Yaniv Bronheim" , > > > "Shahar Havivi" > > > Sent: Thursday, July 21, 2016 2:17:19 PM > > > Subject: Re: [ovirt-devel] execCmd() and storing stdout and stderr in log > > > file > > > > > > On Thu, Jul 21, 2016 at 1:51 PM, Tomáš Golembiovský > > > wrote: > > > > On Thu, 21 Jul 2016 03:26:44 -0400 (EDT) > > > > Francesco Romani wrote: > > [...] > > > >> I think is time to wrap up so Tomas can finish his work. > > > >> > > > >> So, the options on the table are: > > > >> 1. Build pipelines in python (Nir's approach above) > > > >> - looks like the the fix is in cpopen 1.4.1, available > > > > > > > > X. One more option that occured to me is: use Nir's approach but use > > > >subprocess.Popen directly. > > > > > > Until we integrate with subprocess32, you should use compat.CPopen. > > > > > > When subprocess32 is ready, the correct way would be compat.Popen, > > > hiding the subprocess32 import on Python 2.7. > > > > > > > - since Yaniv said updated cpopen won't be available for 4.0 > > > > > > We don't need the update for 4.0, cpopen 1.4.1, available in 4.0 should be > > > good enough. > > I still see only 1.4 in repos. But if there will be 1.4.1 for 4.0 it is > good enough. So it's tagged as 1.4.1 but packaged as 1.4-1. Well you got me there. Anyway, I'm glad I have the package. -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Thu, 21 Jul 2016 08:24:57 -0400 (EDT) Francesco Romani wrote: > - Original Message - > > From: "Nir Soffer" > > To: "Tomáš Golembiovský" > > Cc: "Francesco Romani" , "devel" , > > "Yaniv Bronheim" , > > "Shahar Havivi" > > Sent: Thursday, July 21, 2016 2:17:19 PM > > Subject: Re: [ovirt-devel] execCmd() and storing stdout and stderr in log > > file > > > > On Thu, Jul 21, 2016 at 1:51 PM, Tomáš Golembiovský > > wrote: > > > On Thu, 21 Jul 2016 03:26:44 -0400 (EDT) > > > Francesco Romani wrote: > [...] > > >> I think is time to wrap up so Tomas can finish his work. > > >> > > >> So, the options on the table are: > > >> 1. Build pipelines in python (Nir's approach above) > > >> - looks like the the fix is in cpopen 1.4.1, available > > > > > > X. One more option that occured to me is: use Nir's approach but use > > >subprocess.Popen directly. > > > > Until we integrate with subprocess32, you should use compat.CPopen. > > > > When subprocess32 is ready, the correct way would be compat.Popen, > > hiding the subprocess32 import on Python 2.7. > > > > > - since Yaniv said updated cpopen won't be available for 4.0 > > > > We don't need the update for 4.0, cpopen 1.4.1, available in 4.0 should be > > good enough. I still see only 1.4 in repos. But if there will be 1.4.1 for 4.0 it is good enough. > > > > > - and since we're aiming for subprocess.Popen in a log run anyway (if > > > my > > >understanding is correct) > > > > Correct, but we did not integrated with it yet > > > > > - and since the package for python-subprocess32 is available in our > > > 4.0 > > >dependencies repo already > > > > Really? > > > > I think subprocess32 is not available yet on rhel, so we cannot use it yet. > > > > Tomas, could you please check about the availability in RHEL? > So, turns out we have only one option (and half? :)) which is good, it > simplifies > the things. It turned out the python-subprocess32 is available from our centos-ovirt40-candidate[1] repo. Not in RHEL as such. > > > >> 2. add options to execCmd to redirect stderr > > >>- make execCmd even bigger, makes everyone grumpy > > >>- could require a couple of simple fixes (talked with > > >> Tomas privately, nothing groundbreaking - like one between stdout > > >> and stderr could be None and we must cope with that) > > > > This is not an option, execCmd is too big and ugly today, we are not going > > to add more features to it. > > > > This helper is the way to use for the common case of running a process, > > collecting the data from both stdout and stderr, and returning the results. > > > > Code that have special needs should not use execCmd. I didn't know that. > > > > See qemuimg.QemuImgOperation, and storage.check.DirectioChecker for > > examles. > > > > You should use the helpers in cmdutils for consistent logging when starting > > and finishing a process. > > Fine, and thanks for the examples. > > > > > >> 3. DUP execCmd just for v2v and just to avoid making it more complex > > >>- see https://gerrit.ovirt.org/#/c/60660/ > > >>- even worse than extending execCmd? > > >>- still needs the fixes above > > > > No, one is enough > > Indeed it is, going to abandon 60660 and bury it very deep as soon as we > reach consensus. > > > > > >> 4. use shell tricks and reuse existing execCmd > > >>- reviewers/future selves needs to wrap their head on that shell magic > > >>- PERHAPS fragile? I don't really know > > > > I would not use the shell if I don't have to. > > ok, let's keep this as very last resort. > > > There are other issues - where do you save the import log > > (per-import log file?, v2v.log?) and how the logs are deleted. > > Indeed they are, but I'm less worried about those since are been already > solved > in the past and we already have tools to deal with them Logs will be stored in /var/log/vdsm/imports. > > Maybe keep per-import log files, in /var/log/vdsm/v2v, and use logrotate > > configuration to rotate them? > > I think we though about this (me and Tomas) in the past, and that was the > plan; > Anyway I agree with this, let's make this our plan if it wasn't already :) I didn't bother with setup for logrotate yet. The import process is not something happening automatically or regularly. It's unlikely the user will end up with full /var partition because of that. If you believe it's necessary it can be done. [1] http://cbs.centos.org/repos/virt7-ovirt-40-candidate/x86_64/os/ -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Thu, 21 Jul 2016 03:26:44 -0400 (EDT) Francesco Romani wrote: > - Original Message - > > From: "Nir Soffer" > > To: "Yaniv Bronheim" > > Cc: "Shahar Havivi" , "Richard Jones" > > , "devel" > > Sent: Tuesday, July 19, 2016 4:18:31 PM > > Subject: Re: [ovirt-devel] execCmd() and storing stdout and stderr in log > > file > > > > On Tue, Jul 19, 2016 at 5:07 PM, Yaniv Bronheim > > wrote: > > > > > > On Tue, Jul 19, 2016 at 4:56 PM, Tomáš Golembiovský > > > wrote: > > >> > > >> On Thu, 14 Jul 2016 17:25:28 +0300 > > >> Nir Soffer wrote: > > >> > > >> > After https://gerrit.ovirt.org/#/c/46733/ you should be able to create > > >> > the pipeline in python like this: > > >> > > > >> > v2v = Popen(["virt-v2v", ...], stdout=PIPE, stderr=STDOUT) > > >> > tee = Popen(["tee", "-a", logfile], stdin=v2v.stdout, stdout=PIPE, > > >> > stderr=PIPE) > > >> > > > >> > Now we can read output from tee.stdout, and when tee is finished, we > > >> > can > > >> > wait > > >> > for v2v to get the exit code. > > >> > > > >> > Since all output would go to tee stdout and stderr may only contain tee > > >> > usage > > >> > errors, we don't need to use AsyncProc, making this code python 3 > > >> > compatible. > > >> > > >> > > >> Yes, this may actualy work. And do we plan to adopt the cpopen 1.4.1, > > >> where > > >> this is fixed, in VDSM? > > > > > > > > > cpopen 1.5.1 - and yes but not in ovirt-4.0 > > > > It is included in 1.4.1, released ages ago. > > > > $ git log --oneline --decorate > > 826b5ef (HEAD -> master, origin/master, origin/HEAD) Raise version for 1.5 > > build > > a9d2a72 (inherit-fds) Add tests for disabling the close-on-exec flag > > 7163e79 Do not close inherited fds from parent > > 1b170fb (gerrit/master) Raising release number and tagging cpopen 1.4.1 > > 69ae841 Sort imports to make it easier to add new imports > > 1116830 Simplify tests using CPopen.communicate() > > 58e1b43 Remove unneeded and wrong retry after fork > > fbf9ff3 Remove wrong and unneeded retry for execv > > 74ee4a0 Do not retry close() after interrupt > > 1abde2b Use _exit to terminate child after failure > > 8709c42 Fix incorrect fd closing > > > > $ git show 1b170fb --format=fuller > > commit 1b170fb8f2d204457ca66e53936fd3a059f4ed4b > > Author: Yaniv Bronhaim > > AuthorDate: Wed Oct 14 15:40:07 2015 +0300 > > Commit: Yaniv Bronhaim > > CommitDate: Wed Oct 14 09:36:31 2015 -0400 > > > > Raising release number and tagging cpopen 1.4.1 > > > > Recent patches include only bug fixes. see commit messages > > > > Change-Id: Ia1d32dd5bd7f60681b64251cef217c8d1e41b14b > > Signed-off-by: Yaniv Bronhaim > > Thanks to everyone for comments and insights. > > I think is time to wrap up so Tomas can finish his work. > > So, the options on the table are: > 1. Build pipelines in python (Nir's approach above) > - looks like the the fix is in cpopen 1.4.1, available X. One more option that occured to me is: use Nir's approach but use subprocess.Popen directly. - since Yaniv said updated cpopen won't be available for 4.0 - and since we're aiming for subprocess.Popen in a log run anyway (if my understanding is correct) - and since the package for python-subprocess32 is available in our 4.0 dependencies repo already > 2. add options to execCmd to redirect stderr >- make execCmd even bigger, makes everyone grumpy >- could require a couple of simple fixes (talked with > Tomas privately, nothing groundbreaking - like one between stdout > and stderr could be None and we must cope with that) > 3. DUP execCmd just for v2v and just to avoid making it more complex >- see https://gerrit.ovirt.org/#/c/60660/ >- even worse than extending execCmd? >- still needs the fixes above > 4. use shell tricks and reuse existing execCmd >- reviewers/future selves needs to wrap their head on that shell magic >- PERHAPS fragile? I don't really know > 5. something else I forgot? > > > I think the approaches here are ordered by likeness and feasibility, > so I'd actually try in this order (1->2->3->4) > > Please ACK/NACK the above, so Tomas can conclude this patch > for next monday (20160725) > > -- > Francesco Romani > RedHat Engineering Virtualization R & D > Phone: 8261328 > IRC: fromani -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Thu, 14 Jul 2016 17:25:28 +0300 Nir Soffer wrote: > After https://gerrit.ovirt.org/#/c/46733/ you should be able to create > the pipeline in python like this: > > v2v = Popen(["virt-v2v", ...], stdout=PIPE, stderr=STDOUT) > tee = Popen(["tee", "-a", logfile], stdin=v2v.stdout, stdout=PIPE, > stderr=PIPE) > > Now we can read output from tee.stdout, and when tee is finished, we can wait > for v2v to get the exit code. > > Since all output would go to tee stdout and stderr may only contain tee usage > errors, we don't need to use AsyncProc, making this code python 3 compatible. Yes, this may actualy work. And do we plan to adopt the cpopen 1.4.1, where this is fixed, in VDSM? -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Thu, 14 Jul 2016 15:07:29 +0300 Nir Soffer wrote: > On Mon, Jul 11, 2016 at 12:53 PM, Tomáš Golembiovský > wrote: > > On Wed, 6 Jul 2016 18:37:54 +0300 > > Yaniv Bronheim wrote: > > > >> On Wed, Jul 6, 2016 at 5:07 PM, Tomáš Golembiovský > >> wrote: > >> > >> > > >> > Merging stdout and stderr to one can POpen do for us, I belive. Any > >> > logging can indeed be done as a wrapper around execCmd. > >> > >> saving stdout and err to log while the process is running is useful only > >> for your purpose currently. using asyncproc as you do now in v2v allows you > >> to to run a process and monitor it.. can you use overriding of aysncProc > >> wrapper for your needs instead of changing cpopen or execcmd code? > > > > I am not talking about CPOpen. I meant that when calling > > `subprocess.Popen`, you can pass it `stderr=subprocess.STDOUT` argument > > and it will handle the FD redirection (stream merging). To me it seems > > like a proper way of doing this. > > This should work with execCmd, since the special subprocess.STDOUT > parameter is handled in subprocess.Popen, and cpopen.CPopen inherit > this code. However this is not tested with cpopen, so it may be broken. > > But merging stdout and stderr is likely to break v2v output parser, and vdsm > log is not the place for virt-v2v debug logs. This is something that we can deal with. > > I understand that the issue is keeping virt-v2v debug logs (using --verbose?), > and the logs are spread in stdout and stderr. Did you discuss this issue > with Richard? Not yet. > > I would use tee to write stdout and stderr to an import log file, without > changing the code checking import progress. This is something I have tried as first, as you can see here: https://gerrit.ovirt.org/#/c/59834/4/lib/vdsm/v2v.py@404 The problem with this approach is that we don't get proper exit code from virt-v2v because of the pipe. Fixing this in POSIX shell is not trivial and would lead to more complex shell code here. (Would be fairly easy to fix if we could resort to using bash here.) > > Maybe virt-v2v can add a --logfile option appending to given log file? > > Richard, what do you think? > > > > > > >> > > [...] > >> > > > >> > > btw, after examine the area again, isn't watchCmd func is what you > >> > > describe? we just need to replace the asyncProc usages there with > >> > > something that doesn't use StringIO as we do to support py3 > >> > > >> > I'm not sure how watchCmd can help with this. Isn't it just a wrapper to > >> > get asynchrounous process with a stop condition? > >> > > >> > >> it is. thought you need something similar and afterwards log the outputs > > > > I can run async process with `execCmd` directly and I don't need any > > stop condition. Am I missing something that `watchCmd` provides? > > > > -- > > Tomáš Golembiovský > > ___ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Thu, 14 Jul 2016 07:06:38 -0400 (EDT) Francesco Romani wrote: > > useful you can add those parameters to execCmd > > Good news about cpopen! > > Is it a good idea to add even more parameters to execCmd? Let's discuss this. > > another approach I could think of is https://gerrit.ovirt.org/#/c/60660/ > I'm not that proud of 60660 either, this is why it is a draft :\ > > So I've been in touch with Tomas, and he kindly tried to rebase his code > on top of my 60660, but looks like he was biten by issues fixed in > https://gerrit.ovirt.org/#/c/59181/ > https://gerrit.ovirt.org/#/c/59095/ Actualy it has probably been fixed (as a side effect) of this: https://gerrit.ovirt.org/#/c/46733/ > I think leveraging cpopen is a good way, it is simple enough and it doesn't > hurt our plans to eventually move to subprocess. There is another problem with AsyncProc. When we pass `stderr=STDOUT` to popen the returned object has None in stderr property. This is something AsyncProc does not expect. It can be fixed with something like this: https://gerrit.ovirt.org/#/c/60727/ -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Wed, 6 Jul 2016 18:37:54 +0300 Yaniv Bronheim wrote: > On Wed, Jul 6, 2016 at 5:07 PM, Tomáš Golembiovský > wrote: > > > > > Merging stdout and stderr to one can POpen do for us, I belive. Any > > logging can indeed be done as a wrapper around execCmd. > > saving stdout and err to log while the process is running is useful only > for your purpose currently. using asyncproc as you do now in v2v allows you > to to run a process and monitor it.. can you use overriding of aysncProc > wrapper for your needs instead of changing cpopen or execcmd code? I am not talking about CPOpen. I meant that when calling `subprocess.Popen`, you can pass it `stderr=subprocess.STDOUT` argument and it will handle the FD redirection (stream merging). To me it seems like a proper way of doing this. > > > [...] > > > > > > btw, after examine the area again, isn't watchCmd func is what you > > > describe? we just need to replace the asyncProc usages there with > > > something that doesn't use StringIO as we do to support py3 > > > > I'm not sure how watchCmd can help with this. Isn't it just a wrapper to > > get asynchrounous process with a stop condition? > > > > it is. thought you need something similar and afterwards log the outputs I can run async process with `execCmd` directly and I don't need any stop condition. Am I missing something that `watchCmd` provides? -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Tue, 5 Jul 2016 11:18:58 +0300 Yaniv Bronheim wrote: > On Tue, Jul 5, 2016 at 10:44 AM, Yaniv Bronheim wrote: > > > Hi > > I do work to remove the cpopen usages from execCmd. Using std popen over > > py3 and subprocess32 over py2 which both implements the same api. The only > > gap is the output object for async calls that we need to align with the > > standard implementation and modify our current usages. I don't think that > > adding more non-standard logics to execCmd is a good idea. we should fit > > the standard usage in this function or override it separately with specific > > implementation in commands.py. You may propose such patch Sure, that makes sense. Are there any existing drafts/patches I could look at or help with? Merging stdout and stderr to one can POpen do for us, I belive. Any logging can indeed be done as a wrapper around execCmd. > [...] > > btw, after examine the area again, isn't watchCmd func is what you > describe? we just need to replace the asyncProc usages there with > something that doesn't use StringIO as we do to support py3 I'm not sure how watchCmd can help with this. Isn't it just a wrapper to get asynchrounous process with a stop condition? Could you elaborate on why we want to get rid of StringIO in AsyncProc? If I understand it right, it's purpose is to make sure the executed program doesn't stall on full pipe if VDSM isn't fast enough in processing the output. Or am I missing something? But it could again be implemented as a wrapper around execCmd and not in it. Is that what you mean? -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] execCmd() and storing stdout and stderr in log file
Hi, I had a need recently to run a command with execCmd() and store it's output and error to a log file, while still receiving it in the calling code. Redirecting the error to output stream to have all in one stream is also useful feature. All this can be done in the calling code: a) On the shell level, by modyfing the command. This can be intentionally dangerous because things like quoting of arguments has to be considered and also could cause problems when wrappers (sudo, nice, ...) are used. b) By handling the writing to files in a code. This would add unnecessary code duplication in a long run. (I don't think I'm the only one who can see a potential in this.) Also for asynchronous process runs, when storing both stderr & stdout in one file, it requires polling and some stream magic. It would be better to have this done right and only once so it can be properly tested. That's why I think having it present in execCmd() ready for everyone's use is the best solution. Unfortunately it seems that the code is a) essential on many places in vdsm and b) not properly covered by tests. Which makes it hard to touch. Also apparently some refactoring is either planned or already underway. What is the situation about refactoring that code area? Anyone working on it? Do we have an estimation of time-frame for it? Any suggestions/ideas? Tomas -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Undelivered mail warnings from Gerrit
Hi, for the last two weeks I've been getting lots of warnings about undelivered mail from Gerrit. The importnat thing in the message being: The original message was received at Wed, 1 Jun 2016 14:57:54 -0400 from gerrit.ovirt.org [127.0.0.1] - Transcript of session follows - ... Deferred: Connection timed out with hosted-lists01.fedoraproject.org. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old Anyone else experiencing the same problem? Is this being worked on? -- Tomáš Golembiovský ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
