[ovirt-devel] Re: Yuriy about NVMe over fabrics for oVirt

[Nir Soffer]

On Thu, Nov 2, 2023 at 4:40 PM Yuriy  wrote:

> Hi Nir!
>
> This is Yuriy.
> We agreed to continue the subject via email.
>

So the options are:

1. Using Managed Block Storage (cinderlib) with a driver that supports
NVMe/TCP.

Lastest oVirt has the needed changes to configure this. Benny and I tested
with Lightbits[1] driver in a
virtualized environment. This is basically a POC that may work for you or
not, or require more work
that you will have to do yourself since not much development is happening
now in oVirt.

2. Using the devices via multipath

Legacy storage domains are based on multipath. It may be possible to use
multipath on top of
NVMe devices, and in this case they look like a normal LUN so you can
create a storage domain
from such devices.

oVirt will not handle connections for you, and all the devices must be
connected to all nodes at the
same time, just like FC/iSCSI LUNs. You will likely not get the performance
benefit of NVMe/TCP.

3. Using host devices

If what you need is using some devices (which happen to be connected via be
NVMe/TCP), maybe you
can attach them to a VM directly (using host devices). This gives the best
possible performance but no
features (snapshots, backup, live migration, live storage migration, etc.)

[1] https://www.lightbitslabs.com/

Nir
___
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/C7G4T7AZ2QWZXEU4BAA2WTG3WGQPLQBQ/

[ovirt-devel] Enable DCO app on github for enforcing signed-off-by

[Nir Soffer]

I'm not sure we enforce signed-off-by in all projects, but we do in the
most important
projects. There is a nice little app adding CI check with zero effort. Here
is
a bad commit:

https://github.com/nirs/userstorage/pull/29

When the check fails the app provides useful help for users:


https://github.com/nirs/userstorage/pull/29/checks?check_run_id=9125092601

Looks like very little effort to improve all projects!

If you wandered what signed-off-by means, this is explained here:

https://wiki.linuxfoundation.org/dco

Nir
___
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/WM6H2MXLZ27FGDRRX7VZEINVJXNMYPXA/

[ovirt-devel] Re: github testing: merge with branch, or use PR HEAD?

[Nir Soffer]

On Wed, Jun 15, 2022 at 12:26 PM Yedidyah Bar David  wrote:
>
> Hi all,
>
> I was annoyed for some time now by the fact that when I used some
> github-CI-generated RPMs, with a git hash in their names, I could
> never find this git hash anywhere - not in my local git repo, nor in
> github. Why is it so? Because, if I got it right, the default for
> 'actions/checkout@v2' is to merge the PR HEAD with the branch HEAD.
> See e.g. [1]:
>
> HEAD is now at 7bbb40c9a Merge
> 026bb9c672bf46786dd6d16f4cbe0ecfa84c531d into
> 35e217936b5571e9657946b47333a563373047bb
>
> Meaning: my patch was 026bb9c, master was 35e2179, and the generated
> RPMs will have 7bbb40c9a, not to be found anywhere else. If you check
> the main PR page [3], you can find there '026bb9c', but not
> '7bbb40c9a'.
>
> (Even 026bb9c might require some effort, e.g. "didib force-pushed the
> add-hook-log-console branch 2 times, most recently from c90e658 to
> 66ebc88 yesterday". I guess this is the result of github discouraging
> force-pushes, in direct opposite of gerrit, which had a notion of
> different patchsets for a single change. I already ranted about this
> in the past, but that's not the subject of the current message).
>
> This is not just an annoyance, it's a real difference in semantics. In
> gerrit/jenkins days, IIRC most/all projects I worked on, ran CI
> testing/building on the pushed HEAD, and didn't touch it. Rebase, if
> at all, happened either explicitly, or at merge time.

I don't think that the action *rebases* the pr, it uses a merge commit
but this adds newer commits on master on top of the pr, which may
conflict or change the semantics of the pr.

> actions/checkout's default, to auto-merge, is probably meant to be
> more "careful" - to test what would happen if the code is merged. I
> agree this makes sense. But I personally think it's almost always ok
> to test on the pushed HEAD and not rebase/merge _implicitely_.
>
> What do you think?

I agree, this is unexpected and unwanted behavior in particular for
projects that disable merge commits (e.g. vdsm).

> It should be easy to change, using [2]:
>
> - uses: actions/checkout@v2
>   with:
> ref: ${{ github.event.pull_request.head.sha }}

+1

Nir
___
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/WZ3W6BII34CTQXXLBYJB6W6ECCWEGM4J/

[ovirt-devel] Re: Projects missing safe dir config in COPR

[Nir Soffer]

On Mon, Jun 13, 2022 at 1:39 PM Michal Skrivanek  wrote:
>
> Hi,
> I scanned the current projects and AFAICT these are the active projects that 
> don't have builds configured properly. Please add "git config --global --add 
> safe.directory ..." to the COPR makefile
> Otherwise COPR build may not work at all or (worse) they build something 
> wrong.

For example way to fix this issue see:
https://github.com/oVirt/vdsm/commit/64873df82480006fce743baa89b83b94c41e53e7
https://github.com/oVirt/ovirt-imageio/commit/a72c680782584db17597dd3116e0a1dca7290249

>
> Thanks,
> michal
>
>
> imgbased
> ioprocess

Fixed in
https://github.com/oVirt/ioprocess/pull/2

> mom
> ovirt-ansible-collection
> ovirt-cockpit-sso
> ovirt-engine-api-metamodel
> ovirt-engine-api-model
> ovirt-engine-wildfly
> ovirt-hosted-engine-ha
> ovirt-hosted-engine-setup
> ovirt-lldp-labeler
> ovirt-log-collector
> ovirt-node-ng
> ovirt-openvswitch
> ovirt-setup-lib
> ovirt-vmconsole
> python-ovirt-engine-sdk4

Nir
___
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/BMUD4NBMGB4JDVAJKV5BC7TLWJ2IDAE6/

[ovirt-devel] engine-setup fail with least ovirt-engine

[Nir Soffer]

I upgraded today to
ovirt-engine-4.5.1-0.2.master.20220414121739.gitb2384c6521.el8.noarch

Engine setup failed to complete when restarting httpd:

# engine-setup
...
[ INFO  ] Restarting httpd
[ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'httpd'
[ INFO  ] Stage: Clean up
  Log file is located at
/var/log/ovirt-engine/setup/ovirt-engine-setup-20220418000357-gn9jww.log
[ INFO  ] Generating answer file
'/var/lib/ovirt-engine/setup/answers/20220418000447-setup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of setup failed

[root@engine ~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled;
vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2022-04-18 00:04:47 IDT; 19s ago
 Docs: man:httpd.service(8)
  Process: 15359 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
(code=exited, status=1/FAILURE)
 Main PID: 15359 (code=exited, status=1/FAILURE)
   Status: "Reading configuration..."

Apr 18 00:04:47 engine.local systemd[1]: Starting The Apache HTTP Server...
Apr 18 00:04:47 engine.local httpd[15359]: [Mon Apr 18 00:04:47.727854
2022] [so:warn] [pid 15359:tid 140623023360320] AH01574: mo>
Apr 18 00:04:47 engine.local httpd[15359]: AH00526: Syntax error on
line 4 of /etc/httpd/conf.d/zz-ansible-runner-service.conf:
Apr 18 00:04:47 engine.local httpd[15359]: Invalid command
'WSGIDaemonProcess', perhaps misspelled or defined by a module not
incl>

After installing python3-mod_wsgi httpd can be started, and engine-setup works.

Do we miss requires: in the spec?

Nir
___
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/GGK2OUA4V7FHE4QMGPZIPKUCVN2G5BYQ/

[ovirt-devel] Re: [ovirt-users] [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Tue, Mar 29, 2022 at 3:26 AM JC Lopez  wrote:
>
> Hi Nir,
>
> Tried to do this but somehow the UI does not let me drag the network anywhere 
> in the window.
>
> Just in case I tried with both the host in maintenance mode and not in 
> maintenance mode. Tried drag and drop on any area of the dialog box I could 
> think off without success
>
> Tried with 3 different browsers to rule out browser incompatibility
> - Safari
> - Chrome
> - Firefox
>
>
> So NO idea why no network interfaces are detected on this node. FYI my CPU 
> model is a Broadwell one.
>
> Best regards
> JC
> Initial window sees no network interface
> Clicking on setup network does not have any interface to which I can assign 
> the ovirtmgmt network

I did a clean engine and host installation, and reproduced the same
issue you had.

1. Host is stuck in "Connecting state"
2. Host warning about:
   - no default route
   - incompatible cpu - missing cpu flags
3. No network interfaces

See attached screenshots.

In my setup, the issue was broken /etc/hosts file in engine host.
Before I started, I had a working engine (built few weeks ago) with
/etc/hosts file with all the oVirt hosts in my environment.

After running engine-cleanup and engine-setup, and removing fighting
with snsible versions (updating ansible removed ovirt-engine, updating
ovirt-engine requires using --nobest), my /etc/hosts was replaced with
default file with the defaults localhost entries.

After adding back my hosts to /etc/hosts, adding a new fresh
Centos Stream 8 hosts was successful.

Please check if you access the host from engine host using the DNS
name used in engine UI, or the IP address.

I think we need an engine bug for this - when the host is not reachable from
engine adding a host should fail fast with a clear message about an unreachable
host, instead of the bogus errors about default route and incompatible CPU.

Nir
___
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/RC7MVA7YF2KG5H234VPFV246EPNRZDN2/

[ovirt-devel] Re: [ovirt-users] [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Wed, Mar 30, 2022 at 11:26 PM JC Lopez  wrote:
>
> Hi Nir,
>
> Wiped out the node as the procedure provided did not fix the problem.
>
> Fresh CentOS Stream 8
>
> Looks like the vddm I deployed requires Ansible 2.12
> Depsolve Error occured: \n Problem: cannot install the best candidate for the 
> job\n  - nothing provides virt-install needed by 
> ovirt-hosted-engine-setup-2.6.4-0.0.master.20220329124709.git59931a1.el8.noarch\n
>   - nothing provides ansible-core >= 2.12 needed by 
> ovirt-hosted-engine-setup-2.6.4-0.0.master.20220329124709.git59931a1.el8.noarch”,

Didi, do we have a solution to the ansible requirement? Maybe some
repo is missing?

> But the ovirt-engine requires Ansible 2.9.27-2
> package 
> ovirt-engine-4.5.0.1-0.2.master.20220330145541.gitaff1492753.el8.noarch 
> conflicts with ansible-core >= 2.10.0 provided by 
> ansible-core-2.12.2-2.el8.x86_64
>
> So if I enable all my repos the deployment wants to deploy packages that 
> require 2.12 but because of the oVirt-manager requirements it says it can not 
> pass Ansible 2.10. So I end up in a deadlock situation
>
> Not sure what to do. Will get onto irc tomorrow to check on this with you
>
> Question: When is oVirt 4.5 being officially released. May be it will be 
> easier for me to start from that point.

We should have 4.5 beta next week.

>
> Best regards
> JC
>
>
> On Mar 29, 2022, at 11:08, Nir Soffer  wrote:
>
> On Tue, Mar 29, 2022 at 3:26 AM JC Lopez  wrote:
>
>
> Hi Nir,
>
> Tried to do this but somehow the UI does not let me drag the network anywhere 
> in the window.
>
> Just in case I tried with both the host in maintenance mode and not in 
> maintenance mode. Tried drag and drop on any area of the dialog box I could 
> think off without success
>
> Tried with 3 different browsers to rule out browser incompatibility
> - Safari
> - Chrome
> - Firefox
>
>
> So NO idea why no network interfaces are detected on this node. FYI my CPU 
> model is a Broadwell one.
>
>
> If engine does not detect any network interface "setup networks" is
> not going to be
> very useful.
>
> I'm not sure how you got into this situation, maybe this is an upgrade issue.
>
> I suggest to start clean:
>
> 1. Remove current vdsm install on the host
>
> dnf remove vdsm\*
>
> 2. Upgrade you host to latest CentOS Stream 8
>
> 3. Add the ovirt repos:
> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/
>
> dnf copr enable -y ovirt/ovirt-master-snapshot centos-stream-8
> dnf install -y ovirt-release-master
>
> 4. Make sure your host network configuration is right
>
> You should be able to connect from your engine machine to the host.
>
> 5. Add the host to your engine
>
> Engine will install the host and reboot it. The host should be up when
> this is done.
>
> 6. Add some storage so you have a master storage domain.
>
> The easier way is to add NFS storage domain but you can use also iSCSI
> or FC if you like.
>
> At this point you should have working setup.
>
> The next step is to update engine and vdsm with the Benny patches,
> but don't try this before you have a working system.
>
> If you need more help we can chat in #ovirt on oftc.net.
>
> Nir
>
>
> Best regards
> JC
> Initial window sees no network interface
> Clicking on setup network does not have any interface to which I can assign 
> the ovirtmgmt network
>
>
> On Mar 28, 2022, at 13:38, Nir Soffer  wrote:
>
> On Mon, Mar 28, 2022 at 11:31 PM Nir Soffer  wrote:
>
>
> On Mon, Mar 28, 2022 at 10:48 PM JC Lopez  wrote:
>
>
> Hi Benny et all,
>
> ...
>
> With 4.5 I can not bring the host up
>
> Here is my cluster spec
> In the UI I see the following when trying to add host client2
>
>
> In the screenshot we see 2 issues:
> - host does not default route
> - host cpu missing some features
>
> To resolve the default route issue, click on the host name in the
> "Hosts" page, then
> click on the "Network interfaces", and then "Setup networks" button,
> and make sure
> the ovirtmgmt network is assigned to the right network interface, and
> edit it as needed.
>
>
> Adding screenshot in case it was not clear enough.
>
>
> To quickly avoid this issue, select an older cpu from the list. This
> should be good
> enough for development. Maybe Arik can help with using the actual CPU you 
> have.
>
> However when I check the nodes capabilities using Vdsm client I get this for 
> each flag mentioned
> [root@client2 ~]# vdsm-client Host getCapabilities | grep kvm
> "cpuFlags": 
> "clflush,cqm_llc,

[ovirt-devel] Re: [ovirt-users] [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Tue, Mar 29, 2022 at 3:26 AM JC Lopez  wrote:
>
> Hi Nir,
>
> Tried to do this but somehow the UI does not let me drag the network anywhere 
> in the window.
>
> Just in case I tried with both the host in maintenance mode and not in 
> maintenance mode. Tried drag and drop on any area of the dialog box I could 
> think off without success
>
> Tried with 3 different browsers to rule out browser incompatibility
> - Safari
> - Chrome
> - Firefox
>
>
> So NO idea why no network interfaces are detected on this node. FYI my CPU 
> model is a Broadwell one.

If engine does not detect any network interface "setup networks" is
not going to be
very useful.

I'm not sure how you got into this situation, maybe this is an upgrade issue.

I suggest to start clean:

1. Remove current vdsm install on the host

dnf remove vdsm\*

2. Upgrade you host to latest CentOS Stream 8

3. Add the ovirt repos:
   https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/

dnf copr enable -y ovirt/ovirt-master-snapshot centos-stream-8
dnf install -y ovirt-release-master

4. Make sure your host network configuration is right

You should be able to connect from your engine machine to the host.

5. Add the host to your engine

Engine will install the host and reboot it. The host should be up when
this is done.

6. Add some storage so you have a master storage domain.

The easier way is to add NFS storage domain but you can use also iSCSI
or FC if you like.

At this point you should have working setup.

The next step is to update engine and vdsm with the Benny patches,
but don't try this before you have a working system.

If you need more help we can chat in #ovirt on oftc.net.

Nir

>
> Best regards
> JC
> Initial window sees no network interface
> Clicking on setup network does not have any interface to which I can assign 
> the ovirtmgmt network
>
>
> On Mar 28, 2022, at 13:38, Nir Soffer  wrote:
>
> On Mon, Mar 28, 2022 at 11:31 PM Nir Soffer  wrote:
>
>
> On Mon, Mar 28, 2022 at 10:48 PM JC Lopez  wrote:
>
>
> Hi Benny et all,
>
> ...
>
> With 4.5 I can not bring the host up
>
> Here is my cluster spec
> In the UI I see the following when trying to add host client2
>
>
> In the screenshot we see 2 issues:
> - host does not default route
> - host cpu missing some features
>
> To resolve the default route issue, click on the host name in the
> "Hosts" page, then
> click on the "Network interfaces", and then "Setup networks" button,
> and make sure
> the ovirtmgmt network is assigned to the right network interface, and
> edit it as needed.
>
>
> Adding screenshot in case it was not clear enough.
>
>
> To quickly avoid this issue, select an older cpu from the list. This
> should be good
> enough for development. Maybe Arik can help with using the actual CPU you 
> have.
>
> However when I check the nodes capabilities using Vdsm client I get this for 
> each flag mentioned
> [root@client2 ~]# vdsm-client Host getCapabilities | grep kvm
> "cpuFlags": 
> "clflush,cqm_llc,sdbg,abm,movbe,bmi1,intel_ppin,apic,sse2,mce,arat,amd-ssbd,monitor,xsaveopt,ida,bmi2,pclmulqdq,ssse3,pni,ss,rdrand,xsave,avx2,intel_pt,sse4_2,ept_ad,stibp,rdseed,pse,dts,dtes64,3dnowprefetch,cpuid_fault,acpi,fsgsbase,cdp_l3,x2apic,fpu,invpcid_single,sse4_1,pti,amd-stibp,ht,pae,pat,tsc,mmx,nonstop_tsc,pdcm,ssbd,invpcid,cqm,de,lahf_lm,vpid,smep,tm,vmx,bts,rdtscp,flexpriority,rtm,pse36,smap,cqm_mbm_total,cmov,smx,skip-l1dfl-vmentry,est,tm2,hypervisor,pge,tsc_deadline_timer,invtsc,nx,pbe,f16c,vnmi,nopl,epb,cx8,msr,umip,pcid,aperfmperf,xtpr,avx,cqm_occup_llc,pdpe1gb,constant_tsc,tsc_adjust,sse,arch_perfmon,ept,ibrs,adx,dtherm,pschange-mc-no,cat_l3,rep_good,ibpb,pln,fma,sep,aes,pts,syscall,xtopology,rdt_a,erms,cpuid,flush_l1d,vme,cx16,popcnt,mca,cqm_mbm_local,mtrr,arch-capabilities,dca,tpr_shadow,lm,ds_cpl,fxsr,hle,pebs,spec_ctrl,model_Opteron_G1,model_486,model_Broadwell-noTSX-IBRS,model_Westmere-IBRS,model_IvyBridge-IBRS,model_Conroe,model_Opteron_G2,model_Broadwell-noTSX,model_qemu32,model_Haswell,model_Westmere,model_Haswell-IBRS,model_core2duo,model_Broadwell-IBRS,model_Broadwell,model_n270,model_Haswell-noTSX-IBRS,model_IvyBridge,model_pentium3,model_Penryn,model_Nehalem,model_kvm64,model_qemu64,model_SandyBridge-IBRS,model_coreduo,model_Haswell-noTSX,model_Nehalem-IBRS,model_kvm32,model_pentium,model_SandyBridge,model_pentium2",
> "kvmEnabled": "true",
> "qemu-kvm": {
> "kvm"
> [root@client2 ~]# vdsm-client Host getCapabilities | grep nx
> "cpuFlags": 
> "clflush,cqm_llc,sdbg,abm,movbe,bmi1,intel_ppin,apic,sse2,mce,arat,amd-ssbd,monitor,xsaveopt,ida,bmi2,pclmulqdq,ssse3,pni,ss,rdrand,xsave,avx2,intel_pt,sse4_2,ep

[ovirt-devel] Re: [ovirt-users] [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Mon, Mar 28, 2022 at 10:48 PM JC Lopez  wrote:
>
> Hi Benny et all,
...
> With 4.5 I can not bring the host up
>
> Here is my cluster spec
> In the UI I see the following when trying to add host client2

In the screenshot we see 2 issues:
- host does not default route
- host cpu missing some features

To resolve the default route issue, click on the host name in the
"Hosts" page, then
click on the "Network interfaces", and then "Setup networks" button,
and make sure
the ovirtmgmt network is assigned to the right network interface, and
edit it as needed.

To quickly avoid this issue, select an older cpu from the list. This
should be good
enough for development. Maybe Arik can help with using the actual CPU you have.

> However when I check the nodes capabilities using Vdsm client I get this for 
> each flag mentioned
> [root@client2 ~]# vdsm-client Host getCapabilities | grep kvm
> "cpuFlags": 
> "clflush,cqm_llc,sdbg,abm,movbe,bmi1,intel_ppin,apic,sse2,mce,arat,amd-ssbd,monitor,xsaveopt,ida,bmi2,pclmulqdq,ssse3,pni,ss,rdrand,xsave,avx2,intel_pt,sse4_2,ept_ad,stibp,rdseed,pse,dts,dtes64,3dnowprefetch,cpuid_fault,acpi,fsgsbase,cdp_l3,x2apic,fpu,invpcid_single,sse4_1,pti,amd-stibp,ht,pae,pat,tsc,mmx,nonstop_tsc,pdcm,ssbd,invpcid,cqm,de,lahf_lm,vpid,smep,tm,vmx,bts,rdtscp,flexpriority,rtm,pse36,smap,cqm_mbm_total,cmov,smx,skip-l1dfl-vmentry,est,tm2,hypervisor,pge,tsc_deadline_timer,invtsc,nx,pbe,f16c,vnmi,nopl,epb,cx8,msr,umip,pcid,aperfmperf,xtpr,avx,cqm_occup_llc,pdpe1gb,constant_tsc,tsc_adjust,sse,arch_perfmon,ept,ibrs,adx,dtherm,pschange-mc-no,cat_l3,rep_good,ibpb,pln,fma,sep,aes,pts,syscall,xtopology,rdt_a,erms,cpuid,flush_l1d,vme,cx16,popcnt,mca,cqm_mbm_local,mtrr,arch-capabilities,dca,tpr_shadow,lm,ds_cpl,fxsr,hle,pebs,spec_ctrl,model_Opteron_G1,model_486,model_Broadwell-noTSX-IBRS,model_Westmere-IBRS,model_IvyBridge-IBRS,model_Conroe,model_Opteron_G2,model_Broadwell-noTSX,model_qemu32,model_Haswell,model_Westmere,model_Haswell-IBRS,model_core2duo,model_Broadwell-IBRS,model_Broadwell,model_n270,model_Haswell-noTSX-IBRS,model_IvyBridge,model_pentium3,model_Penryn,model_Nehalem,model_kvm64,model_qemu64,model_SandyBridge-IBRS,model_coreduo,model_Haswell-noTSX,model_Nehalem-IBRS,model_kvm32,model_pentium,model_SandyBridge,model_pentium2",
> "kvmEnabled": "true",
> "qemu-kvm": {
> "kvm"
> [root@client2 ~]# vdsm-client Host getCapabilities | grep nx
> "cpuFlags": 
> "clflush,cqm_llc,sdbg,abm,movbe,bmi1,intel_ppin,apic,sse2,mce,arat,amd-ssbd,monitor,xsaveopt,ida,bmi2,pclmulqdq,ssse3,pni,ss,rdrand,xsave,avx2,intel_pt,sse4_2,ept_ad,stibp,rdseed,pse,dts,dtes64,3dnowprefetch,cpuid_fault,acpi,fsgsbase,cdp_l3,x2apic,fpu,invpcid_single,sse4_1,pti,amd-stibp,ht,pae,pat,tsc,mmx,nonstop_tsc,pdcm,ssbd,invpcid,cqm,de,lahf_lm,vpid,smep,tm,vmx,bts,rdtscp,flexpriority,rtm,pse36,smap,cqm_mbm_total,cmov,smx,skip-l1dfl-vmentry,est,tm2,hypervisor,pge,tsc_deadline_timer,invtsc,nx,pbe,f16c,vnmi,nopl,epb,cx8,msr,umip,pcid,aperfmperf,xtpr,avx,cqm_occup_llc,pdpe1gb,constant_tsc,tsc_adjust,sse,arch_perfmon,ept,ibrs,adx,dtherm,pschange-mc-no,cat_l3,rep_good,ibpb,pln,fma,sep,aes,pts,syscall,xtopology,rdt_a,erms,cpuid,flush_l1d,vme,cx16,popcnt,mca,cqm_mbm_local,mtrr,arch-capabilities,dca,tpr_shadow,lm,ds_cpl,fxsr,hle,pebs,spec_ctrl,model_Opteron_G1,model_486,model_Broadwell-noTSX-IBRS,model_Westmere-IBRS,model_IvyBridge-IBRS,model_Conroe,model_Opteron_G2,model_Broadwell-noTSX,model_qemu32,model_Haswell,model_Westmere,model_Haswell-IBRS,model_core2duo,model_Broadwell-IBRS,model_Broadwell,model_n270,model_Haswell-noTSX-IBRS,model_IvyBridge,model_pentium3,model_Penryn,model_Nehalem,model_kvm64,model_qemu64,model_SandyBridge-IBRS,model_coreduo,model_Haswell-noTSX,model_Nehalem-IBRS,model_kvm32,model_pentium,model_SandyBridge,model_pentium2",
> [root@client2 ~]# vdsm-client Host getCapabilities | grep vmx
> "cpuFlags": 
> 

[ovirt-devel] Re: [ovirt-users] querying which LUNs are associated to a specific VM disks

[Nir Soffer]

On Fri, Mar 18, 2022 at 10:13 AM Sandro Bonazzola 
wrote:

> I got a question on oVirt Itala Telegram group about how to get which LUNs
> are used by the disks attached to a specific VMs.
> This information doesn't seem to be exposed in API or within the engine DB.
> Has anybody ever tried something like this?
>

We don't expose this, but you can find it using lvm.

For example for disk id c5401e6c-9c56-4ddf-b57a-efde3f8b0494

# lvs -o vg_name,lv_name,devices --devicesfile='' --select 'lv_tags =
{IU_c5401e6c-9c56-4ddf-b57a-efde3f8b0494}'
  VG   LV
Devices
  aecec81f-d464-4a35-9a91-6acf2ca4938c dea573e4-734c-405c-9c2c-590dac63122c
/dev/mapper/36001405351b21217d814266b5354d710(141)

141 is the first extent used by the disk on the device
/dev/mapper/36001405351b21217d814266b5354d710.

A disk with snapshots can have many logical volumes. Each logical
volume can use one or more luns in the storage domain.

The example works with oVirt 4.5, using lvmdevices. For older versions
using lvm filter you can use:

--config 'devices { filter = ["|.*|" ] }'

This info is not static, lvm may move data around, so we cannot keep it
in engine db. Getting the info is pretty cheap, one lvs command can
return the info for all disks in a storage domain.

Nir
___
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/HROXAM3ISRLNCSCJXMAC5QYEHUZB5RDS/

[ovirt-devel] Re: Vdsm: SonarCloud CI failures

[Nir Soffer]

On Tue, Mar 15, 2022 at 7:02 PM Nir Soffer  wrote:
>
> On Tue, Mar 15, 2022 at 6:10 PM Milan Zamazal  wrote:
> >
> > Hi,
> >
> > SonarClouds checks are run on the Vdsm GitHub repo, with occasional
> > failures, see for example https://github.com/oVirt/vdsm/pull/94 (I'm
> > pretty sure I've seen other similar failures recently, probably hidden
> > by later, successful runs).  The failures report too many duplicate
> > lines in places completely unrelated to a given patch.  This disturbs
> > CI reports.
> >
> > Does anybody know why SonarClouds checks are run on the Vdsm repo (they
> > don't seem to be run on other repos, e.g. ovirt-engine)?  Are the checks
> > useful for anybody?  If not, is it possible to disable them?
>
> I find these reports unhelpful.
>
> We don't have any control on the checks done, and we cannot disable them.
> Even when we had admin rights on the vdsm project, there was no way to disable
> this unwanted integration.
>
> We already use pylint and flake8 checks are part of vdsm CI workflow,
> and for these
> checks we have full control on what is checked, for example:
> https://github.com/oVirt/vdsm/blob/master/pylintrc
>
> +1 to remove this integration.

Sandro, do you know why SonarClouds is integrated in the vdsm project
and how to remove it?
___
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/OLIWKD2SB7NHS6PVWNKEZAZCLHSKU5RF/

[ovirt-devel] Re: Vdsm: SonarCloud CI failures

[Nir Soffer]

On Tue, Mar 15, 2022 at 6:10 PM Milan Zamazal  wrote:
>
> Hi,
>
> SonarClouds checks are run on the Vdsm GitHub repo, with occasional
> failures, see for example https://github.com/oVirt/vdsm/pull/94 (I'm
> pretty sure I've seen other similar failures recently, probably hidden
> by later, successful runs).  The failures report too many duplicate
> lines in places completely unrelated to a given patch.  This disturbs
> CI reports.
>
> Does anybody know why SonarClouds checks are run on the Vdsm repo (they
> don't seem to be run on other repos, e.g. ovirt-engine)?  Are the checks
> useful for anybody?  If not, is it possible to disable them?

I find these reports unhelpful.

We don't have any control on the checks done, and we cannot disable them.
Even when we had admin rights on the vdsm project, there was no way to disable
this unwanted integration.

We already use pylint and flake8 checks are part of vdsm CI workflow,
and for these
checks we have full control on what is checked, for example:
https://github.com/oVirt/vdsm/blob/master/pylintrc

+1 to remove this integration.

Nir
___
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/5MT5R3S35VDHR7YHC5NHMK3CYH35ZUXL/

[ovirt-devel] Re: [ovirt-users] Re: [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Fri, Feb 25, 2022 at 12:04 PM Gorka Eguileor  wrote:
>
> On 24/02, Nir Soffer wrote:
> > On Thu, Feb 24, 2022 at 8:46 PM Gorka Eguileor  wrote:
> > >
> > > On 24/02, Nir Soffer wrote:
> > > > On Thu, Feb 24, 2022 at 6:35 PM Muli Ben-Yehuda 
> > > >  wrote:
> > > > >
> > > > > On Thu, Feb 24, 2022 at 6:28 PM Nir Soffer  wrote:
> > > > >>
> > > > >> On Thu, Feb 24, 2022 at 6:10 PM Muli Ben-Yehuda 
> > > > >>  wrote:
> > > > >> >
> > > > >> > On Thu, Feb 24, 2022 at 3:58 PM Nir Soffer  
> > > > >> > wrote:
> > > > >> >>
> > > > >> >> On Wed, Feb 23, 2022 at 6:24 PM Muli Ben-Yehuda 
> > > > >> >>  wrote:
> > > > >> >> >
> > > > >> >> > Thanks for the detailed instructions, Nir. I'm going to 
> > > > >> >> > scrounge up some hardware.
> > > > >> >> > By the way, if anyone else would like to work on NVMe/TCP 
> > > > >> >> > support, for NVMe/TCP target you can either use Lightbits (talk 
> > > > >> >> > to me offline for details) or use the upstream Linux NVMe/TCP 
> > > > >> >> > target. Lightbits is a clustered storage system while upstream 
> > > > >> >> > is a single target, but the client side should be close enough 
> > > > >> >> > for vdsm/ovirt purposes.
> > > > >> >>
> > > > >> >> I played with NVMe/TCP a little bit, using qemu to create a 
> > > > >> >> virtual
> > > > >> >> NVMe disk, and export
> > > > >> >> it using the kernel on one VM, and consume it on another VM.
> > > > >> >> https://futurewei-cloud.github.io/ARM-Datacenter/qemu/nvme-of-tcp-vms/
> > > > >> >>
> > > > >> >> One question about device naming - do we always get the same name 
> > > > >> >> of the
> > > > >> >> device in all hosts?
> > > > >> >
> > > > >> >
> > > > >> > No, we do not, see below how we handle migration in os_brick.
> > > > >> >
> > > > >> >> To support VM migration, every device must have unique name in 
> > > > >> >> the cluster.
> > > > >> >> With multipath we always have unique name, since we disable 
> > > > >> >> "friendly names",
> > > > >> >> so we always have:
> > > > >> >>
> > > > >> >> /dev/mapper/{wwid}
> > > > >> >>
> > > > >> >> With rbd we also do not use /dev/rbdN but a unique path:
> > > > >> >>
> > > > >> >> /dev/rbd/poolname/volume-vol-id
> > > > >> >>
> > > > >> >> How do we ensure cluster-unique device path? If os_brick does not 
> > > > >> >> handle it, we
> > > > >> >> can to do in ovirt, for example:
> > > > >> >>
> > > > >> >> /run/vdsm/mangedvolumes/{uuid} -> /dev/nvme7n42
> > > > >> >>
> > > > >> >> but I think this should be handled in cinderlib, since openstack 
> > > > >> >> have
> > > > >> >> the same problem with migration.
> > > > >> >
> > > > >> >
> > > > >> > Indeed. Both the Lightbits LightOS connector and the nvmeof 
> > > > >> > connector do this through the target provided namespace (LUN) 
> > > > >> > UUID. After connecting to the target, the connectors wait for the 
> > > > >> > local friendly-named device file that has the right UUID to show 
> > > > >> > up, and then return the friendly name. So different hosts will 
> > > > >> > have different friendly names, but the VMs will be attached to the 
> > > > >> > right namespace since we return the friendly name on the current 
> > > > >> > host that has the right UUID. Does this also work for you?
> > > > >>
> > > > >> It will not work for oVirt.
> > > > >>
> > > > >> Migration in oVirt works l

[ovirt-devel] Re: [ovirt-users] Re: [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Thu, Feb 24, 2022 at 8:46 PM Gorka Eguileor  wrote:
>
> On 24/02, Nir Soffer wrote:
> > On Thu, Feb 24, 2022 at 6:35 PM Muli Ben-Yehuda  
> > wrote:
> > >
> > > On Thu, Feb 24, 2022 at 6:28 PM Nir Soffer  wrote:
> > >>
> > >> On Thu, Feb 24, 2022 at 6:10 PM Muli Ben-Yehuda  
> > >> wrote:
> > >> >
> > >> > On Thu, Feb 24, 2022 at 3:58 PM Nir Soffer  wrote:
> > >> >>
> > >> >> On Wed, Feb 23, 2022 at 6:24 PM Muli Ben-Yehuda 
> > >> >>  wrote:
> > >> >> >
> > >> >> > Thanks for the detailed instructions, Nir. I'm going to scrounge up 
> > >> >> > some hardware.
> > >> >> > By the way, if anyone else would like to work on NVMe/TCP support, 
> > >> >> > for NVMe/TCP target you can either use Lightbits (talk to me 
> > >> >> > offline for details) or use the upstream Linux NVMe/TCP target. 
> > >> >> > Lightbits is a clustered storage system while upstream is a single 
> > >> >> > target, but the client side should be close enough for vdsm/ovirt 
> > >> >> > purposes.
> > >> >>
> > >> >> I played with NVMe/TCP a little bit, using qemu to create a virtual
> > >> >> NVMe disk, and export
> > >> >> it using the kernel on one VM, and consume it on another VM.
> > >> >> https://futurewei-cloud.github.io/ARM-Datacenter/qemu/nvme-of-tcp-vms/
> > >> >>
> > >> >> One question about device naming - do we always get the same name of 
> > >> >> the
> > >> >> device in all hosts?
> > >> >
> > >> >
> > >> > No, we do not, see below how we handle migration in os_brick.
> > >> >
> > >> >> To support VM migration, every device must have unique name in the 
> > >> >> cluster.
> > >> >> With multipath we always have unique name, since we disable "friendly 
> > >> >> names",
> > >> >> so we always have:
> > >> >>
> > >> >> /dev/mapper/{wwid}
> > >> >>
> > >> >> With rbd we also do not use /dev/rbdN but a unique path:
> > >> >>
> > >> >> /dev/rbd/poolname/volume-vol-id
> > >> >>
> > >> >> How do we ensure cluster-unique device path? If os_brick does not 
> > >> >> handle it, we
> > >> >> can to do in ovirt, for example:
> > >> >>
> > >> >> /run/vdsm/mangedvolumes/{uuid} -> /dev/nvme7n42
> > >> >>
> > >> >> but I think this should be handled in cinderlib, since openstack have
> > >> >> the same problem with migration.
> > >> >
> > >> >
> > >> > Indeed. Both the Lightbits LightOS connector and the nvmeof connector 
> > >> > do this through the target provided namespace (LUN) UUID. After 
> > >> > connecting to the target, the connectors wait for the local 
> > >> > friendly-named device file that has the right UUID to show up, and 
> > >> > then return the friendly name. So different hosts will have different 
> > >> > friendly names, but the VMs will be attached to the right namespace 
> > >> > since we return the friendly name on the current host that has the 
> > >> > right UUID. Does this also work for you?
> > >>
> > >> It will not work for oVirt.
> > >>
> > >> Migration in oVirt works like this:
> > >>
> > >> 1. Attach disks to destination host
> > >> 2. Send VM XML from source host to destination host, and start the
> > >>VM is paused mode
> > >> 3. Start the migration on the source host
> > >> 4. When migration is done, start the CPU on the destination host
> > >> 5. Detach the disks from the source
> > >>
> > >> This will break in step 2, since the source xml refer to nvme device
> > >> that does not exist or already used by another VM.
> > >
> > >
> > > Indeed.
> > >
> > >> To make this work, the VM XML must use the same path, existing on
> > >> both hosts.
> > >>
> > >> The issue can be solved by libvirt hook updating the paths before qemu
> > >> is started on the destina

[ovirt-devel] Re: [ovirt-users] Re: [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Thu, Feb 24, 2022 at 6:35 PM Muli Ben-Yehuda  wrote:
>
> On Thu, Feb 24, 2022 at 6:28 PM Nir Soffer  wrote:
>>
>> On Thu, Feb 24, 2022 at 6:10 PM Muli Ben-Yehuda  
>> wrote:
>> >
>> > On Thu, Feb 24, 2022 at 3:58 PM Nir Soffer  wrote:
>> >>
>> >> On Wed, Feb 23, 2022 at 6:24 PM Muli Ben-Yehuda  
>> >> wrote:
>> >> >
>> >> > Thanks for the detailed instructions, Nir. I'm going to scrounge up 
>> >> > some hardware.
>> >> > By the way, if anyone else would like to work on NVMe/TCP support, for 
>> >> > NVMe/TCP target you can either use Lightbits (talk to me offline for 
>> >> > details) or use the upstream Linux NVMe/TCP target. Lightbits is a 
>> >> > clustered storage system while upstream is a single target, but the 
>> >> > client side should be close enough for vdsm/ovirt purposes.
>> >>
>> >> I played with NVMe/TCP a little bit, using qemu to create a virtual
>> >> NVMe disk, and export
>> >> it using the kernel on one VM, and consume it on another VM.
>> >> https://futurewei-cloud.github.io/ARM-Datacenter/qemu/nvme-of-tcp-vms/
>> >>
>> >> One question about device naming - do we always get the same name of the
>> >> device in all hosts?
>> >
>> >
>> > No, we do not, see below how we handle migration in os_brick.
>> >
>> >> To support VM migration, every device must have unique name in the 
>> >> cluster.
>> >> With multipath we always have unique name, since we disable "friendly 
>> >> names",
>> >> so we always have:
>> >>
>> >> /dev/mapper/{wwid}
>> >>
>> >> With rbd we also do not use /dev/rbdN but a unique path:
>> >>
>> >> /dev/rbd/poolname/volume-vol-id
>> >>
>> >> How do we ensure cluster-unique device path? If os_brick does not handle 
>> >> it, we
>> >> can to do in ovirt, for example:
>> >>
>> >> /run/vdsm/mangedvolumes/{uuid} -> /dev/nvme7n42
>> >>
>> >> but I think this should be handled in cinderlib, since openstack have
>> >> the same problem with migration.
>> >
>> >
>> > Indeed. Both the Lightbits LightOS connector and the nvmeof connector do 
>> > this through the target provided namespace (LUN) UUID. After connecting to 
>> > the target, the connectors wait for the local friendly-named device file 
>> > that has the right UUID to show up, and then return the friendly name. So 
>> > different hosts will have different friendly names, but the VMs will be 
>> > attached to the right namespace since we return the friendly name on the 
>> > current host that has the right UUID. Does this also work for you?
>>
>> It will not work for oVirt.
>>
>> Migration in oVirt works like this:
>>
>> 1. Attach disks to destination host
>> 2. Send VM XML from source host to destination host, and start the
>>VM is paused mode
>> 3. Start the migration on the source host
>> 4. When migration is done, start the CPU on the destination host
>> 5. Detach the disks from the source
>>
>> This will break in step 2, since the source xml refer to nvme device
>> that does not exist or already used by another VM.
>
>
> Indeed.
>
>> To make this work, the VM XML must use the same path, existing on
>> both hosts.
>>
>> The issue can be solved by libvirt hook updating the paths before qemu
>> is started on the destination, but I think the right way to handle this is to
>> have the same path.
>
>
>  You mentioned above that it can be handled in ovirt (c.f., 
> /run/vdsm/mangedvolumes/{uuid} -> /dev/nvme7n42), which seems like a 
> reasonable approach given the constraint imposed by the oVirt migration flow 
> you outlined above. What information does vdsm need to create and use the 
> /var/run/vdsm/managedvolumes/{uuid} link? Today the connector does (trimmed 
> for brevity):
>
> def connect_volume(self, connection_properties):
> device_info = {'type': 'block'}
> uuid = connection_properties['uuid']
> device_path = self._get_device_by_uuid(uuid)
> device_info['path'] = device_path
> return device_info

I think we have 2 options:

1. unique path created by os_brick using the underlying uuid

In this case the connector will return the uuid, and ovirt will use
it to resolve the unique path that will be stored and used on engine
s

[ovirt-devel] Re: [ovirt-users] Re: [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Thu, Feb 24, 2022 at 6:10 PM Muli Ben-Yehuda  wrote:
>
> On Thu, Feb 24, 2022 at 3:58 PM Nir Soffer  wrote:
>>
>> On Wed, Feb 23, 2022 at 6:24 PM Muli Ben-Yehuda  
>> wrote:
>> >
>> > Thanks for the detailed instructions, Nir. I'm going to scrounge up some 
>> > hardware.
>> > By the way, if anyone else would like to work on NVMe/TCP support, for 
>> > NVMe/TCP target you can either use Lightbits (talk to me offline for 
>> > details) or use the upstream Linux NVMe/TCP target. Lightbits is a 
>> > clustered storage system while upstream is a single target, but the client 
>> > side should be close enough for vdsm/ovirt purposes.
>>
>> I played with NVMe/TCP a little bit, using qemu to create a virtual
>> NVMe disk, and export
>> it using the kernel on one VM, and consume it on another VM.
>> https://futurewei-cloud.github.io/ARM-Datacenter/qemu/nvme-of-tcp-vms/
>>
>> One question about device naming - do we always get the same name of the
>> device in all hosts?
>
>
> No, we do not, see below how we handle migration in os_brick.
>
>> To support VM migration, every device must have unique name in the cluster.
>> With multipath we always have unique name, since we disable "friendly names",
>> so we always have:
>>
>> /dev/mapper/{wwid}
>>
>> With rbd we also do not use /dev/rbdN but a unique path:
>>
>> /dev/rbd/poolname/volume-vol-id
>>
>> How do we ensure cluster-unique device path? If os_brick does not handle it, 
>> we
>> can to do in ovirt, for example:
>>
>> /run/vdsm/mangedvolumes/{uuid} -> /dev/nvme7n42
>>
>> but I think this should be handled in cinderlib, since openstack have
>> the same problem with migration.
>
>
> Indeed. Both the Lightbits LightOS connector and the nvmeof connector do this 
> through the target provided namespace (LUN) UUID. After connecting to the 
> target, the connectors wait for the local friendly-named device file that has 
> the right UUID to show up, and then return the friendly name. So different 
> hosts will have different friendly names, but the VMs will be attached to the 
> right namespace since we return the friendly name on the current host that 
> has the right UUID. Does this also work for you?

It will not work for oVirt.

Migration in oVirt works like this:

1. Attach disks to destination host
2. Send VM XML from source host to destination host, and start the
   VM is paused mode
3. Start the migration on the source host
4. When migration is done, start the CPU on the destination host
5. Detach the disks from the source

This will break in step 2, since the source xml refer to nvme device
that does not exist or already used by another VM.

To make this work, the VM XML must use the same path, existing on
both hosts.

The issue can be solved by libvirt hook updating the paths before qemu
is started on the destination, but I think the right way to handle this is to
have the same path.

Nir
___
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/PHRJI6SL6AFWTVXHLFH3RS4W4E3CE3GK/

[ovirt-devel] Re: [ovirt-users] Re: [=EXTERNAL=] Re: help using nvme/tcp storage with cinderlib and Managed Block Storage

[Nir Soffer]

On Wed, Feb 23, 2022 at 6:24 PM Muli Ben-Yehuda  wrote:
>
> Thanks for the detailed instructions, Nir. I'm going to scrounge up some 
> hardware.
> By the way, if anyone else would like to work on NVMe/TCP support, for 
> NVMe/TCP target you can either use Lightbits (talk to me offline for details) 
> or use the upstream Linux NVMe/TCP target. Lightbits is a clustered storage 
> system while upstream is a single target, but the client side should be close 
> enough for vdsm/ovirt purposes.

I played with NVMe/TCP a little bit, using qemu to create a virtual
NVMe disk, and export
it using the kernel on one VM, and consume it on another VM.
https://futurewei-cloud.github.io/ARM-Datacenter/qemu/nvme-of-tcp-vms/

One question about device naming - do we always get the same name of the
device in all hosts?

To support VM migration, every device must have unique name in the cluster.
With multipath we always have unique name, since we disable "friendly names",
so we always have:

/dev/mapper/{wwid}

With rbd we also do not use /dev/rbdN but a unique path:

/dev/rbd/poolname/volume-vol-id

How do we ensure cluster-unique device path? If os_brick does not handle it, we
can to do in ovirt, for example:

/run/vdsm/mangedvolumes/{uuid} -> /dev/nvme7n42

but I think this should be handled in cinderlib, since openstack have
the same problem
with migration.

Nir

>
> Cheers,
> Muli
> --
> Muli Ben-Yehuda
> Co-Founder and Chief Scientist @ http://www.lightbitslabs.com
> LightOS: The Special Storage Sauce For Your Cloud
>
>
> On Wed, Feb 23, 2022 at 4:55 PM Nir Soffer  wrote:
>>
>> On Wed, Feb 23, 2022 at 4:20 PM Muli Ben-Yehuda  
>> wrote:
>> >
>> > Thanks, Nir and Benny (nice to run into you again, Nir!). I'm a neophyte 
>> > in ovirt and vdsm... What's the simplest way to set up a development 
>> > environment? Is it possible to set up a "standalone" vdsm environment to 
>> > hack support for nvme/tcp or do I need "full ovirt" to make it work?
>>
>> It should be possible to install vdsm on a single host or vm, and use vdsm
>> API to bring the host to the right state, and then attach devices and run
>> vms. But I don't know anyone that can pull this out since simulating what
>> engine is doing is hard.
>>
>> So the best way is to set up at least one host and engine host using the
>> latest 4.5 rpms, and continue from there. Once you have a host, building
>> vdsm on the host and upgrading the rpms is pretty easy.
>>
>> My preferred setup is to create vms using virt-manager for hosts, engine
>> and storage and run all the vms on my laptop.
>>
>> Note that you must have some traditional storage (NFS/iSCSI) to bring up
>> the system even if you plan to use only managed block storage (MBS).
>> Unfortunately when we add MBS support we did have time to fix the huge
>> technical debt so you still need a master storage domain using one of the
>> traditional legacy options.
>>
>> To build a setup, you can use:
>>
>> - engine vm: 6g ram, 2 cpus, centos stream 8
>> - hosts vm: 4g ram, 2 cpus, centos stream 8
>>   you can start with one host and add more hosts later if you want to
>> test migration.
>> - storage vm: 2g ram, 2 cpus, any os you like, I use alpine since it
>> takes very little
>>   memory and its NFS server is fast.
>>
>> See vdsm README for instructions how to setup a host:
>> https://github.com/oVirt/vdsm#manual-installation
>>
>> For engine host you can follow:
>> https://ovirt.org/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/#Enabling_the_Red_Hat_Virtualization_Manager_Repositories_install_RHVM
>>
>> And after that this should work:
>>
>> dnf install ovirt-engine
>> engine-setup
>>
>> Accepting all the defaults should work.
>>
>> When you have engine running, you can add a new host with
>> the ip address or dns name of you host(s) vm, and engine will
>> do everything for you. Note that you must install the ovirt-release-master
>> rpm on the host before you add it to engine.
>>
>> Nir
>>
>> >
>> > Cheers,
>> > Muli
>> > --
>> > Muli Ben-Yehuda
>> > Co-Founder and Chief Scientist @ http://www.lightbitslabs.com
>> > LightOS: The Special Storage Sauce For Your Cloud
>> >
>> >
>> > On Wed, Feb 23, 2022 at 4:16 PM Nir Soffer  wrote:
>> >>
>> >> On Wed, Feb 23, 2022 at 2:48 PM Benny Zlotnik  wrote:
>> >> >
>> >> > So I started looking in the logs and tried to follow along with the
>> &

[ovirt-devel] Re: imageio failure (was: [oVirt/ovirt-release] Failed repoclosure job (Issue #71))

[Nir Soffer]

On Sun, Jan 16, 2022 at 12:18 PM Yedidyah Bar David  wrote:
>
> On Sun, Jan 16, 2022 at 10:50 AM Nir Soffer  wrote:
> >
> > On Sun, Jan 16, 2022 at 10:03 AM Yedidyah Bar David  wrote:
> >>
> >> On Sun, Jan 16, 2022 at 9:11 AM github-actions[bot]
> >>  wrote:
> >> >
> >> > ❌ The repoclosure CI job is still failing. Please investigate.
> >>
> >> https://github.com/oVirt/ovirt-release/runs/4830975790?check_suite_focus=true
> >>
> >> Copr repo for ovirt-master-snapshot owned by ov 168 kB/s | 3.3 kB 00:00
> >> Error: Repoclosure ended with unresolved dependencies.
> >> package: ovirt-imageio-client-2.4.1-0.202201152029.gite226a5f.el8.x86_64
> >> from copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
> >> unresolved deps:
> >> ovirt-imageio-common = 2.4.1-0.202201152029.gite226a5f.el8
> >> package: ovirt-imageio-daemon-2.4.1-0.202201152029.gite226a5f.el8.x86_64
> >> from copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
> >> unresolved deps:
> >> ovirt-imageio-common = 2.4.1-0.202201152029.gite226a5f.el8
> >> Error: Process completed with exit code 1.
> >>
> >> I also see a failure here, not sure it's related:
> >>
> >> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/package/ovirt-imageio/
> >> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/build/3188967/
> >> https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03188967-ovirt-imageio/builder-live.log.gz
> >>
> >> ERROR: Command failed:
> >>  # /usr/bin/systemd-nspawn -q -M e2c8282d0fd84261a27858b46be976be -D
> >> /var/lib/mock/centos-stream-9-x86_64-bootstrap-1642278641.264613/root
> >> -a --capability=cap_ipc_lock --rlimit=RLIMIT_NOFILE=10240
> >> --capability=cap_ipc_lock
> >> --bind=/tmp/mock-resolv.ifotg3xd:/etc/resolv.conf --console=pipe
> >> --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
> >> --setenv=HOME=/var/lib/mock/centos-stream-9-x86_64-1642278641.264613/root/installation-homedir
> >> --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
> >> --setenv=PROMPT_COMMAND=printf "\033]0;\007"
> >> --setenv=PS1= \s-\v\$  --setenv=LANG=C.UTF-8
> >> --setenv=LC_MESSAGES=C.UTF-8
> >> --setenv=LD_PRELOAD=/var/tmp/tmp.mock.jav2ocjj/$LIB/nosync.so
> >> --setenv=SYSTEMD_NSPAWN_TMPFS_TMP=0 --resolv-conf=off /usr/bin/dnf
> >> builddep --installroot
> >> /var/lib/mock/centos-stream-9-x86_64-1642278641.264613/root/
> >> --releasever 9 --setopt=deltarpm=False --allowerasing
> >> --disableplugin=local --disableplugin=spacewalk
> >> --disableplugin=versionlock --disableplugin=local
> >> --disableplugin=spacewalk --disableplugin=versionlock
> >> /var/lib/mock/centos-stream-9-x86_64-1642278641.264613/root//builddir/build/SRPMS/ovirt-imageio-2.4.1-0.202201152029.gite226a5f.el9.src.rpm
> >> --setopt=tsflags=nocontexts --setopt=tsflags=nocontexts
> >> --setopt=tsflags=nocontexts
> >> No matches found for the following disable plugin patterns: local,
> >> spacewalk, versionlock
> >> Copr repository  29 kB/s | 3.3 kB 00:00
> >> Additional repo https_buildlogs_centos_org_cent  18 kB/s | 3.0 kB 00:00
> >> Additional repo https_download_copr_fedorainfra  31 kB/s | 3.3 kB 00:00
> >> Error:
> >>  Problem: cannot install the best candidate for the job
> >>   - nothing provides libgomp = 11.2.1-7.4.el9 needed by
> >> gcc-11.2.1-7.4.el9.x86_64
> >>   - nothing provides libgcc >= 11.2.1-7.4.el9 needed by
> >> gcc-11.2.1-7.4.el9.x86_64
> >>
> >> If that's indeed the issue, it's probably in the OS, not oVirt, and
> >> hopefully temporary. Didn't check further (yet?).
> >
> >
> > I had this problem yesterday when trying to build centos-9 container. Issue 
> > resolved
> > by removing the cached centos 9 layer (podman rmi ...).
> >
> > I guess this is a temporary issue with centos 9.
>
> I tried to rebuild imageio, and it failed again on el9:
>
> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/build/3189482/
>
> However, repoclosure now passed:
>
> https://github.com/oVirt/ovirt-release/actions/runs/1703987851
>
> FYI. Ignoring, for now. At some point we'll actually want el9 to work...

I reproduced the issue on centos 9 vm:

# dnf update --refresh
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not

[ovirt-devel] Re: imageio failure (was: [oVirt/ovirt-release] Failed repoclosure job (Issue #71))

[Nir Soffer]

On Sun, Jan 16, 2022 at 10:03 AM Yedidyah Bar David  wrote:

> On Sun, Jan 16, 2022 at 9:11 AM github-actions[bot]
>  wrote:
> >
> > ❌ The repoclosure CI job is still failing. Please investigate.
>
>
> https://github.com/oVirt/ovirt-release/runs/4830975790?check_suite_focus=true
>
> Copr repo for ovirt-master-snapshot owned by ov 168 kB/s | 3.3 kB 00:00
> Error: Repoclosure ended with unresolved dependencies.
> package: ovirt-imageio-client-2.4.1-0.202201152029.gite226a5f.el8.x86_64
> from copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
> unresolved deps:
> ovirt-imageio-common = 2.4.1-0.202201152029.gite226a5f.el8
> package: ovirt-imageio-daemon-2.4.1-0.202201152029.gite226a5f.el8.x86_64
> from copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
> unresolved deps:
> ovirt-imageio-common = 2.4.1-0.202201152029.gite226a5f.el8
> Error: Process completed with exit code 1.
>
> I also see a failure here, not sure it's related:
>
>
> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/package/ovirt-imageio/
>
> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/build/3188967/
>
> https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03188967-ovirt-imageio/builder-live.log.gz
>
> ERROR: Command failed:
>  # /usr/bin/systemd-nspawn -q -M e2c8282d0fd84261a27858b46be976be -D
> /var/lib/mock/centos-stream-9-x86_64-bootstrap-1642278641.264613/root
> -a --capability=cap_ipc_lock --rlimit=RLIMIT_NOFILE=10240
> --capability=cap_ipc_lock
> --bind=/tmp/mock-resolv.ifotg3xd:/etc/resolv.conf --console=pipe
> --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
>
> --setenv=HOME=/var/lib/mock/centos-stream-9-x86_64-1642278641.264613/root/installation-homedir
> --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
> --setenv=PROMPT_COMMAND=printf "\033]0;\007"
> --setenv=PS1= \s-\v\$  --setenv=LANG=C.UTF-8
> --setenv=LC_MESSAGES=C.UTF-8
> --setenv=LD_PRELOAD=/var/tmp/tmp.mock.jav2ocjj/$LIB/nosync.so
> --setenv=SYSTEMD_NSPAWN_TMPFS_TMP=0 --resolv-conf=off /usr/bin/dnf
> builddep --installroot
> /var/lib/mock/centos-stream-9-x86_64-1642278641.264613/root/
> --releasever 9 --setopt=deltarpm=False --allowerasing
> --disableplugin=local --disableplugin=spacewalk
> --disableplugin=versionlock --disableplugin=local
> --disableplugin=spacewalk --disableplugin=versionlock
>
> /var/lib/mock/centos-stream-9-x86_64-1642278641.264613/root//builddir/build/SRPMS/ovirt-imageio-2.4.1-0.202201152029.gite226a5f.el9.src.rpm
> --setopt=tsflags=nocontexts --setopt=tsflags=nocontexts
> --setopt=tsflags=nocontexts
> No matches found for the following disable plugin patterns: local,
> spacewalk, versionlock
> Copr repository  29 kB/s | 3.3 kB 00:00
> Additional repo https_buildlogs_centos_org_cent  18 kB/s | 3.0 kB 00:00
> Additional repo https_download_copr_fedorainfra  31 kB/s | 3.3 kB 00:00
> Error:
>  Problem: cannot install the best candidate for the job
>   - nothing provides libgomp = 11.2.1-7.4.el9 needed by
> gcc-11.2.1-7.4.el9.x86_64
>   - nothing provides libgcc >= 11.2.1-7.4.el9 needed by
> gcc-11.2.1-7.4.el9.x86_64
>
> If that's indeed the issue, it's probably in the OS, not oVirt, and
> hopefully temporary. Didn't check further (yet?).
>

I had this problem yesterday when trying to build centos-9 container. Issue
resolved
by removing the cached centos 9 layer (podman rmi ...).

I guess this is a temporary issue with centos 9.

Nir
___
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/3UFJGOVTRIWV7KCLMGC3FYRHGPYVYFMG/

[ovirt-devel] Re: git backup

[Nir Soffer]

On Wed, Dec 29, 2021 at 12:37 PM Yedidyah Bar David  wrote:
>
> Hi all,
>
> With the decision and on-going process to migrate from gerrit to
> github, we do not anymore have a backup - github used to be a backup
> for gerrit, automatically synced.
>
> Do we want a backup for github? Some options:
>
> 1. Do nothing. github as-is might be good enough, and it also has an
> archive program [1]. AFAICT, right now none of the partners in this
> program allow 'git clone'. There are plans to allow that in the
> future.
>
> 2. Do something custom like we did so far with gerrit->github.
>
> 3. Find some service. Searching for 'github backup' finds lots of
> options. I didn't check any.
>
> Thoughts?

When you use a service, you depend on the service provider to handle
backups. For example, do we have a backup of our mail?

But I think the ovirt project should not depend on a single provider and
have a git mirror somewhere.

I think the most attractive solution is gitlab, which has built-in support for
pulling (and pushing) to/from remote repositories:
https://docs.gitlab.com/ee/user/project/repository/mirror/index.html

We can do this:
1. Create ovirt organization in gitlab
2. Import all projects from github
3. Set up a pull mirror for every project
   https://docs.gitlab.com/ee/user/project/repository/mirror/pull.html

I tried this on my vdsm project in gitlab:
https://gitlab.com/nirs/vdsm

This repo mirrors my vdsm fork in github:
https://github.com/nirs/vdsm

Because it neds only read-only access, there is not authentication
to set up.

Nir
___
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/WNLYSWZOGL2D73Y7M6NQH7UZ4A4GSAFX/

[ovirt-devel] VDSM have moved to github

[Nir Soffer]

We are not using the gerrit project now, and it was changed to read-only.

We are accepting now pull requests on github:
https://github.com/oVirt/vdsm/pulls

To contribute, use the standard github flow:

1. Fork vdsm on github
   Example: https://github.com/nirs/vdsm
   (you need to create a github account if you don't have one)

2. Clone your fork
Example: git clone g...@github.com:nirs/vdsm.git

3. Push changes to your fork and submit pull requests
Example: https://github.com/oVirt/vdsm/pull/28

4. Check the github CI for your pull request
Example: https://github.com/oVirt/vdsm/pull/28/checks

Note: We don't do squash merges. When addressing comments, force push
to your fork.
Example: https://github.com/oVirt/ovirt-imageio/pull/15


Common issues:

1. How do I add reviewers to my pull request?

Once https://github.com/oVirt/vdsm/pull/28 will be merged, we will have
a CODEOWNERS file:
https://github.com/oVirt/vdsm/blob/96320682a8b41e440fbbb8ca624fd73efa95bda0/CODEOWNERS
so github will assign reviews automatically.

Regardless you can add a comment on you patch like:

@{reviewer}  please review.

2. How do I run OST with my pull request?

OST does not run yet automatically. You have 2 choices:
- Run OST locally (ask here how to run it)
- Use the Red Hat OST runner
  (ask on rhev-de...@redhat.com how to use it)

When running OST, you can use the built rpms from your pull request:
https://github.com/oVirt/vdsm/actions/runs/1673718827
(see the artifacts.zip at the bottom)

3. How to backport a patch to stable branches?

Backport your patch(es) on top of the right stable branch (e.g. ovirt-4.4.z).
When you create a pull request, please choose the right branch.
The stable branches maintainers will be added for review automatically.

4. How to compare changes when a contributor submitted a new version?

When contributor force pushes, github shows:

nirs *force-pushed* the inactivity-timeout branch 2 times, most
recently from *790cc4c* to *38d08c8* 22 days ago

Click the "force-pushed" link to see the differences:


https://github.com/oVirt/ovirt-imageio/compare/790cc4c44c9c6577dae0badb3fc6c52052ad1bd2..38d08c8e872ffa964fbdfb475bff775fb80dc7c6

5. How to download a pull request to my machine?

You can use the github command lline tool "gh":

gh pr checkout 28

See https://cli.github.com/ for more info.

(note: I did not try it yet)

6. How do I comment on commit message?

Github does not have this feature, you can use the review comment, or
add a separate
comment.

7. How to run CI on a single patch in my PR?

Github runs the CI for the entire PR. If your PR have several commits,
issues in early commits
fixed in later commits are hidden. To verify that all commits pass the
tests you can post the
submit a new branch to your local fork.

Example flow:

git checkout -b testing-foobar commit-id
git push origin testing-foobar
(check CI on your fork)

Alternatively, use smaller pull requests. You  can submit pull request
based on another pull
request.

Nir
___
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/SUYBAH3UMWAC6U5QH3ON3VNJAUQHFQWB/

[ovirt-devel] Re: [ovirt-users] using stop_reason as a vdsm hook trigger into the UI

[Nir Soffer]

On Mon, Dec 20, 2021 at 9:59 PM Nathanaël Blanchet  wrote:

Adding the devel list since question is more about extending oVirt
...
> The idea is to use the stop_reason element into the vm xml definition. But 
> after hours, I realized that this element is writed to the vm definition file 
> only after the VM has been destroyed.

So you want to run the clean hook only if stop reason == "clean"?

I think the way to integrate hooks is to define a custom property
in the vm, and check if the property was defined in the hook.

For example how the localdisk hook is triggered:

def main():
backend = os.environ.get('localdisk')
if backend is None:
return
if backend not in [BACKEND_LVM, BACKEND_LVM_THIN]:
hooking.log("localdisk-hook: unsupported backend: %r" % backend)
return
...

The hook runs only if the environment variable "localdisk" is defined
and configured properly.

vdsm defines the custom properties as environment variables.

On the engine side, you need to add a user defined property:

 engine-config -s UserDefinedVMProperties='localdisk=^(lvm|lvmthin)$'

And configure a custom property with one of the allowed values, like:

localdisk=lvm

See vdsm_hooks/localdisk/README for more info.

If you want to control the cleanup, by adding a "clean" stop reason only when
needed, this will not help, and vdsm hook is probably not the right way
to integrate this.

If your intent is to clean a vm in some special events, but you want
to integrate
this in engine, maybe you should write an engine ui plugin?

The plugin can show the running vms, and provide a clean button that will
shut down the vm and run your custom code.

But maybe you don't need to integrate this in engine, and having a simple
script using ovirt engine API/SDK to shutdown the vm and run the cleanup
code.

Nir
___
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/V2RYRKKGEPK7PASKYDLD6WZ5F2G6P4KH/

[ovirt-devel] Re: Vdsm: Failing storage tests when run by non-root in a container

[Nir Soffer]

On Thu, Dec 16, 2021 at 10:47 PM Nir Soffer  wrote:

> On Thu, Dec 16, 2021 at 10:14 PM Milan Zamazal 
> wrote:
> >
> > Hi,
> >
> > when I run Vdsm tests as a non-root user in vdsm-test-centos-8
> > container, they systematically fail on several storage tests.  I run the
> > tests as
> >
> >   podman run -it -v $HOME:$HOME --userns=keep-id vdsm-test-centos-8
> $HOME/test.sh
>
> Why do you need the --userns option?
>
> You run this in a container because your development environment
> is not compatible - right?
>
> > where test.sh is
> >
> >   #!/bin/sh
> >
> >   export TRAVIS_CI=1
>

This is not correct for your local container - in travis we run a
privileged container
as root and we create loop devices before the test.


> >   cd .../vdsm
> >   ./autogen.sh --system
> >   make clean
> >   make
>
> I never run autogen and make during the tests, this can be done once
> after checkout or when modifying the makefiles.
>
> >   make lint
> >   make tests
>
> You are missing:
>
> make storage
>
> Without this, a lot of tests will be skipped or xfailed.
>
> >   make tests-storage
> >
> > The failing tests are in devicemapper_test.py, outofprocess_test.py and
> > qemuimg_test.py.  I have also seen a test failure in nbd_test.py but not
> > always.  Is it a problem of the tests or of my environment?
>
> nbd_test.py should be skipped unless you run as root, or have running
> supervdsm serving your user.
>
> I usually run the storage tests like this locally on Fedora (35 now):
>
> make storage
> tox -e storage
>
> Results:
>
> storage/devicemapper_test.py - 5 pass, rest skip
> storage/nbd_test.py - 2 pass, rest skip
> storage/qemuimg_test.py - 2 skips
> storage/outofprocess_test.py - 3 skips, rest pass
>
> 2350 passed, 161 skipped, 102 deselected, 3 xfailed, 13093 warnings in
> 134.80s (0:02:14)
>
> I'll try later using the container.
>
>
I tried this:

podman run --rm -it -v `pwd`:/src:Z --userns=keep-id vdsm-test-centos-8
cd src
make tests-storage

Got 2 test failures:


= FAILURES
==
__
test_block_device_name
___

def test_block_device_name():
devs = glob.glob("/sys/block/*/dev")
dev_name = os.path.basename(os.path.dirname(devs[0]))
with open(devs[0], 'r') as f:
major_minor = f.readline().rstrip()
>   assert devicemapper.device_name(major_minor) == dev_name
E   AssertionError: assert '7:1' == 'loop1'
E - loop1
E + 7:1

This likey failed since there are no loop devices in the container:

bash-4.4$ ls /dev/
console  core  fd  full  mqueue  null  ptmx  pts  random  shm  stderr
 stdin  stdout  tty  urandom  zero

And there is no way to create them, since your run as regular user
and sudo does not work. Event if it works I think you will not be able
to create the loop devices since the container is not privileged.

It may be possible to map the loop devices from the host to the container
but I never tried.


storage/devicemapper_test.py:243: AssertionError
___
test_stop_server_not_running


@broken_on_ci
def test_stop_server_not_running():
# Stopping non-existing server should succeed.
>   nbd.stop_server("no-such-server-uuid")

storage/nbd_test.py:806:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../lib/vdsm/storage/nbd.py:179: in stop_server
info = systemctl.show(service, properties=("LoadState",))
../lib/vdsm/common/systemctl.py:74: in show
out = commands.run(cmd).decode("utf-8")
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

args = ['/usr/bin/systemctl', 'show', '--property=LoadState',
'vdsm-nbd-no-such-server-uuid.service'], input = None, cwd = None
env = None, sudo = False, setsid = False, nice = None, ioclass = None,
ioclassdata = None, reset_cpu_affinity = True

def run(args, input=None, cwd=None, env=None, sudo=False, setsid=False,
nice=None, ioclass=None, ioclassdata=None,
reset_cpu_affinity=True):
"""
Starts a command communicate with it, and wait until the command
terminates. Ensures that the command is killed if an unexpected
error is
raised.

args are logged when command starts, and are included in the

[ovirt-devel] Re: Vdsm: Failing storage tests when run by non-root in a container

[Nir Soffer]

On Thu, Dec 16, 2021 at 10:14 PM Milan Zamazal  wrote:
>
> Hi,
>
> when I run Vdsm tests as a non-root user in vdsm-test-centos-8
> container, they systematically fail on several storage tests.  I run the
> tests as
>
>   podman run -it -v $HOME:$HOME --userns=keep-id vdsm-test-centos-8
$HOME/test.sh

Why do you need the --userns option?

You run this in a container because your development environment
is not compatible - right?

> where test.sh is
>
>   #!/bin/sh
>
>   export TRAVIS_CI=1
>   cd .../vdsm
>   ./autogen.sh --system
>   make clean
>   make

I never run autogen and make during the tests, this can be done once
after checkout or when modifying the makefiles.

>   make lint
>   make tests

You are missing:

make storage

Without this, a lot of tests will be skipped or xfailed.

>   make tests-storage
>
> The failing tests are in devicemapper_test.py, outofprocess_test.py and
> qemuimg_test.py.  I have also seen a test failure in nbd_test.py but not
> always.  Is it a problem of the tests or of my environment?

nbd_test.py should be skipped unless you run as root, or have running
supervdsm serving your user.

I usually run the storage tests like this locally on Fedora (35 now):

make storage
tox -e storage

Results:

storage/devicemapper_test.py - 5 pass, rest skip
storage/nbd_test.py - 2 pass, rest skip
storage/qemuimg_test.py - 2 skips
storage/outofprocess_test.py - 3 skips, rest pass

2350 passed, 161 skipped, 102 deselected, 3 xfailed, 13093 warnings in
134.80s (0:02:14)

I'll try later using the container.

Nir
___
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/I6TONAPTZI4WN3LRZICH7KIIKM5CEDYB/

[ovirt-devel] Re: Vdsm: Failing storage test

[Nir Soffer]

On Thu, Dec 16, 2021 at 1:36 PM Milan Zamazal  wrote:
>
> Hi,
>
> it seems a recent commit causes a storage test failure on GitHub:
>
>   == FAILURES 
> ===
>    test_prepare_connection_without_initiator_name 
> 
>
>   def test_prepare_connection_without_initiator_name():
>   con_def = [{
>   "password": "password",
>   "port": "3260",
>   "iqn": "iqn.2016-01.com.ovirt:444",
>   "connection": "192.168.1.2",
>   "ipv6_enabled": "false",
>   "id": "994a711a-60f3-411a-aca2-0b60f01e8b8c",
>   "user": "",
>   "tpgt": "1",
>   }]
>   >   conn = storageServer._prepare_connections(sd.ISCSI_DOMAIN, con_def)
>   E   AttributeError: module 'vdsm.storage.storageServer' has no 
> attribute '_prepare_connections'
>
> Could you please fix it quickly or disable the test?
>
> @all: Beware that CI on Vdsm no longer runs the tests and patches must
> be tested on GitHub before merging.

Thanks for reporting, fixed in
https://gerrit.ovirt.org/c/vdsm/+/118071

I guess this is a side effect of testing only the top patch in github.
It is much faster but misses inconsistencies in the series.

Once we move to github this should not happen since in github
you cannot merge a partial PR. It can still happen if we checkout
random patch from a PR that was never tested alone, but this is
not very interesting.

Nir
___
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/TZBXJONKLG53B6AJMLHLMVAGSKIPWKKM/

[ovirt-devel] Re: CI not working again

[Nir Soffer]

On Tue, Dec 14, 2021 at 1:09 PM Nir Soffer  wrote:
>
> On Tue, Dec 14, 2021 at 12:13 PM Nir Soffer  wrote:
> ...
> > > > Should we disable all vdsm tests on gerrit, and enable only x64_64 el8
> > > > build artifacts
> > > > so we can at least get working OST?
> > >
> > > I tried this here:
> > > https://gerrit.ovirt.org/c/vdsm/+/118022
> >
> > Patch should be ready, I rebased by current thin-scratch-disks branch on
> > top of it, and some OST jobs started.
>
> Current state:
> https://gerrit.ovirt.org/q/topic:thin-scratch-disks+is:open
>
> 6 patches ready for merge.
> 3 OST runs started successfully
> 3 build artifacts failed (50% success rate) - I retriggered the failed runs
>
> Al the failures happened on el7-worker-02:
> - 
> https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31470/pipeline
> - 
> https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31485/pipeline
> - 
> https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31488/pipeline

Retriggered runs fail again on el7-worker-02:
- 
https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31493/pipeline
- 
https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31490/pipeline

>
> Build history for this host - all builds fail in the last 4 days:
> https://jenkins.ovirt.org/computer/el7-worker-02/builds
>
> Build history for other hosts:
> https://jenkins.ovirt.org/computer/el7-worker-03/builds
>
> Nir
___
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/AYKWKTJXGTBZK65OTVYKCRIBAFFLXLOX/

[ovirt-devel] Re: CI not working again

[Nir Soffer]

On Tue, Dec 14, 2021 at 12:13 PM Nir Soffer  wrote:
...
> > > Should we disable all vdsm tests on gerrit, and enable only x64_64 el8
> > > build artifacts
> > > so we can at least get working OST?
> >
> > I tried this here:
> > https://gerrit.ovirt.org/c/vdsm/+/118022
>
> Patch should be ready, I rebased by current thin-scratch-disks branch on
> top of it, and some OST jobs started.

Current state:
https://gerrit.ovirt.org/q/topic:thin-scratch-disks+is:open

6 patches ready for merge.
3 OST runs started successfully
3 build artifacts failed (50% success rate) - I retriggered the failed runs

Al the failures happened on el7-worker-02:
- 
https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31470/pipeline
- 
https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31485/pipeline
- 
https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31488/pipeline

Build history for this host - all builds fail in the last 4 days:
https://jenkins.ovirt.org/computer/el7-worker-02/builds

Build history for other hosts:
https://jenkins.ovirt.org/computer/el7-worker-03/builds

Nir
___
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/UNZ34TJIQHQOVI6Q7T4BKCULYMDRMMP5/

[ovirt-devel] Re: CI not working again

[Nir Soffer]

On Tue, Dec 14, 2021 at 12:39 AM Nir Soffer  wrote:
>
> On Tue, Dec 14, 2021 at 12:32 AM Nir Soffer  wrote:
> >
> > On Thu, Dec 9, 2021 at 3:04 PM Milan Zamazal  wrote:
> > >
> > > Hi,
> > >
> > > it looks like Jenkins CI jobs don't finish in any reasonable time.  In
> > > case of Vdsm, at least jenkins-psi2 jobs run but they fail early with
> > >
> > >   Cannot download 
> > > x86_64/python3-ioprocess-1.4.2-1.202111071801.git53786ff.el8.x86_64.rpm: 
> > > All mirrors were tried
> > >
> > > Is there a way to get fixed at least one of the runners?
> >
> > I'm using github CI now, no issue seen in the last week.
> >
> > But we have now a wrose issue, build-artifacts job fail randomly in one of
> > the targets. This means there is no way to use the automatic OST run.
> >
> > Should we disable all vdsm tests on gerrit, and enable only x64_64 el8
> > build artifacts
> > so we can at least get working OST?
>
> I tried this here:
> https://gerrit.ovirt.org/c/vdsm/+/118022

Patch should be ready, I rebased by current thin-scratch-disks branch on
top of it, and some OST jobs started.
___
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/2SVJSSHZHKXDGLYDGSTADJ5XVGI3HQHJ/

[ovirt-devel] Re: CI not working again

[Nir Soffer]

.On Tue, Dec 14, 2021 at 11:15 AM Vojtech Juranek  wrote:
...
> > > we should move to GitHub completely ASAP.  The only thing
> > > missing is OST, right?
> >
> >
> > Yes. I think what we need is a way to start OST build with a github
> > pull request url:
> >
> > CUSTOM_REPOS=https://github.com/oVirt/{project}/pull/{7}
> >
> > Or if it is easier, a way to upload zip files to jenkins for running OST.
>
> If Jenkins wipes the workspace before/after each build, that won't be probably
> the most easy way to go. Github actions deliver the rpm in zip file, so we
> basically need
> * download this zip file before build and unzip

This requires Personal Access Token:
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

So we need to add a github users with PAT that can download the built artifacts.

We need to find the artifacts in the build, likey using github API.

For example:
https://github.com/oVirt/ovirt-imageio/actions/runs/1573283335

The artifact we need is the centos-8.zip:
https://github.com/oVirt/ovirt-imageio/suites/4639547952/artifacts/125747744

The URL does not tell us that this is the centos stream 8 artifact, so we need
a way to locate it programatically.

> * create local repo from it (vdsm.repo with baseurl=file://$PATH_TO_UNZIP_DIR)
> * use this local repo instead of previous Jenkins build artifact job URL

This is for a single host, all hosts in OST need to use the new repo.

Another option is to have a web server serving built rpms, e.g.

https://repo.ost.example.com/

And unzip each built rpm before the test to:

/serverroot/93d9ee4f-4cda-403a-a29d-9a3669ee49af/

So we have this layout:

/serverroot/
   93d9ee4f-4cda-403a-a29d-9a3669ee49af/
   repodata/
   *.rpm
   ...

And start the OST job with:


CUSTOM_REPOS=https://repo.ost.example.com/93d9ee4f-4cda-403a-a29d-9a3669ee49af

When the OST job finish, delete
/serverroot/93d9ee4f-4cda-403a-a29d-9a3669ee49af/

This can also work with multiple pull requests, e.g. testing both vdsm
and engine pull request
at the same time.

Nir
___
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/LQNP4UNRCNQF7I7Q7K2BIOZY5SBPK2PZ/

[ovirt-devel] Re: CI not working again

[Nir Soffer]

On Tue, Dec 14, 2021 at 10:14 AM Milan Zamazal  wrote:
>
> Nir Soffer  writes:
>
> > I'm using github CI now, no issue seen in the last week.
> >
> > But we have now a wrose issue, build-artifacts job fail randomly in one of
> > the targets. This means there is no way to use the automatic OST run.
> >
> > Should we disable all vdsm tests on gerrit, and enable only x64_64 el8
> > build artifacts so we can at least get working OST?
>
> Since tests on gerrit are unusable, we should do it this way, good idea.
>
> Nevertheless manually testing patches by pushing them to GitHub is
> tiresome,

This is not that bad, I'm using this flow for a few years:

while work needed:
hack...
push -f github # push to my github fork
check the build in github

git review  # push to gerrit for review

> we should move to GitHub completely ASAP.  The only thing
> missing is OST, right?

Yes. I think what we need is a way to start OST build with a github
pull request url:

CUSTOM_REPOS=https://github.com/oVirt/{project}/pull/{7}

Or if it is easier, a way to upload zip files to jenkins for running OST.

Once we have something like this, we can move vdsm to github.

Triggering OST builds automatically ("gating") is nice to have and
can be done later.

Nir
___
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/Y6CO6UJG6SD4PIUTPWTMBDT7CC6DGDOH/

[ovirt-devel] Re: CI not working again

[Nir Soffer]

On Tue, Dec 14, 2021 at 12:32 AM Nir Soffer  wrote:
>
> On Thu, Dec 9, 2021 at 3:04 PM Milan Zamazal  wrote:
> >
> > Hi,
> >
> > it looks like Jenkins CI jobs don't finish in any reasonable time.  In
> > case of Vdsm, at least jenkins-psi2 jobs run but they fail early with
> >
> >   Cannot download 
> > x86_64/python3-ioprocess-1.4.2-1.202111071801.git53786ff.el8.x86_64.rpm: 
> > All mirrors were tried
> >
> > Is there a way to get fixed at least one of the runners?
>
> I'm using github CI now, no issue seen in the last week.
>
> But we have now a wrose issue, build-artifacts job fail randomly in one of
> the targets. This means there is no way to use the automatic OST run.
>
> Should we disable all vdsm tests on gerrit, and enable only x64_64 el8
> build artifacts
> so we can at least get working OST?

I tried this here:
https://gerrit.ovirt.org/c/vdsm/+/118022
___
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/AOGRM5EBCJEIH6SDEKHTFIOUKU6SETNO/

[ovirt-devel] Re: CI not working again

[Nir Soffer]

On Thu, Dec 9, 2021 at 3:04 PM Milan Zamazal  wrote:
>
> Hi,
>
> it looks like Jenkins CI jobs don't finish in any reasonable time.  In
> case of Vdsm, at least jenkins-psi2 jobs run but they fail early with
>
>   Cannot download 
> x86_64/python3-ioprocess-1.4.2-1.202111071801.git53786ff.el8.x86_64.rpm: All 
> mirrors were tried
>
> Is there a way to get fixed at least one of the runners?

I'm using github CI now, no issue seen in the last week.

But we have now a wrose issue, build-artifacts job fail randomly in one of
the targets. This means there is no way to use the automatic OST run.

Should we disable all vdsm tests on gerrit, and enable only x64_64 el8
build artifacts
so we can at least get working OST?
___
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/RZVXGUKEB5B5RH33L6QV33LOFRPUU5S5/

[ovirt-devel] Re: oVirt Community - open discussion around repositories and workflows

[Nir Soffer]

On Wed, Dec 1, 2021 at 5:50 PM Nir Soffer  wrote:

> On Wed, Dec 1, 2021 at 11:11 AM Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
>
>> Hi all,
>> so far we haven't encounter any blocking issue with this effort, I wanted
>> to propose to decide on oVirt development moving  to GitHub, COPR and CBS.
>> Recent issue with decommissioning of our CI datacenter is a good reminder
>> why we are doing that...
>> What do we want to do?
>> 1) move "ovirt-master-snapshot" compose to COPR
>> it is feasible for all projects except ovirt-node and appliance due to
>> COPR limitations, for these two we plan to use a self-hosted runner in
>> github env.
>> it replaces the "build-artifacts" stdci stage
>> 2) move release to CentOS Community Build System to simplify our oVirt
>> releases
>> replaces our custom releng-tools process and aligns us better with CentOS
>> that is our main (and only) platform we support.
>> 3) move development from Gerrit to GitHub
>> this is a very visible change and affects every oVirt developer. We need
>> a way how to test posted patches and the current stdci "check-patch" stage
>> is overly complex and slow to run, we lack people for stdci maintenance in
>> general (bluntly, it's a dead project). Out of the various options that
>> exist we ended up converging to Github. Why? Just because it's the most
>> simple thing to do for us, with least amount of effort, least amount of
>> additional people and hw resources, with a manageable learning curve. It
>> comes at a price - it only works if we switch our primary development from
>> Gerrit to Github for all the remaining projects. It is a big change to our
>> processes, but I believe we have to go through that transition in order to
>> solve our CI troubles for good.  We started preparing guide and templates
>> to use so that we keep a uniform "look and feel" for all sub-projects, is
>> shall be ready soon.
>>
>> I'd like us to move from "POC" stage to "production", and actively start
>> working on the above, start moving project after project.
>> Let me ask for a final round of thoughts, comments, objections, we are
>> ready to go ahead.
>>
>> It's not going to be easy, but I firmly believe it will greatly improve
>> maintainability of oVirt and reduce overhead that we all struggle with for
>> years.
>>
>
> This is actually pretty easy. We start to work on this last week, and we
> have
> partial CI in place on github and gitlab.
>
> - lint: merged!
> https://github.com/oVirt/vdsm/actions/runs/1526187734
>
> - storage tests:
> https://gerrit.ovirt.org/c/vdsm/+/117882/
> https://github.com/oVirt/vdsm/actions/runs/1526489399
>
> We don't accept pull requests on github yet, but you can open
> pull request for testing, like this:
> https://github.com/oVirt/vdsm/pull/25
> The new CI runs for the pull request.
>
> I also added the same CI pipeline to gitlab:
> https://gitlab.com/nirs/vdsm/-/pipelines/420340180
>
> This will help to avoid locking to github, or backup if github has
> an outage (just happened last week).
>
> The new CI is based on containers, and should be usable locally
> using podman, see:
> https://github.com/oVirt/vdsm/blob/master/tests/start-container
>
> The only thing missing to move to github is a way to trigger OST
> and add OST results when it is done.
>

Update:

- vdsm CI moved to github:
  https://github.com/oVirt/vdsm/actions/runs/1535645571

- vdsm CI in gitlab is almost complete (non-stroage tests missing):
  https://gitlab.com/nirs/vdsm/-/pipelines/421515813/builds

- ovirt-imageio CI moved to gitub:
  https://github.com/oVirt/ovirt-imageio/actions/runs/1535038194

Developers can fork vdsm or ovirt-imageio and test changes on
their forks.

Nir


>
>
>> Thanks,
>> michal
>>
>> On 10. 11. 2021, at 9:17, Sandro Bonazzola  wrote:
>>
>> Hi, here's an update on what has been done so far and how it is going.
>>
>> *COPR*
>> All the oVirt active subprojects are now built on COPR except oVirt
>> Engine Appliance and oVirt Node: I'm still looking into how to build them
>> on COPR.
>>
>> Of those subprojects only the following are not yet built automatically
>> on patch merge event as they have pending patches for enabling the
>> automation:
>> - ovirt-engine-nodejs-modules:
>> https://gerrit.ovirt.org/c/ovirt-engine-nodejs-modules/+/117506
>> - ovirt-engine-ui-extensions:
>> https://gerrit.ovirt.org/c/ovirt-engine-ui-extensions/+/117512
>> - ovirt-web-ui: https://github.com/oVirt/ovirt-web-ui/pull/1532

[ovirt-devel] Integrating OST with artifacts built in github

[Nir Soffer]

Looking this very helpful document
https://ovirt.org/develop/developer-guide/migrating_to_github.html

The suggested solution is to create artifacts.zip with all the rpms
for a project.

But to use the rpms in OST, we need to create a yum repository before uploading
the artifacts, so we can pass a URL of a zip file with a yum repository.

Here is what we have now in ovirt-imageio:

1. We build for multiple distros:
https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e7fbbfb4/.github/workflows/ci.yml#L32

2. Every build creates a repo in exported-artifacts
https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e7fbbfb4/ci/rpm.sh#L7

3. Every build uploads the exported artifacts to rpm-{distro}.zip
https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e7fbbfb4/.github/workflows/ci.yml#L53

An example build:
https://github.com/nirs/ovirt-imageio/actions/runs/1531658722

To start OST manually, developer can copy a link the right zip file
(e.g for centos stream 8):
https://github.com/nirs/ovirt-imageio/suites/4535392764/artifacts/121520882

And pass the link to OST build with parameters job.

In this solution, OST side gets a repo that can be included in the
build without any
additional code or logic - just unzip and use the repo from the directory.

I think this is the minimal solution to allow running OST with built
artifacts from github.

For triggering jobs automatically, we will need a way to find the
right artifacts for a build,
or use some convention for naming the artifacts in all projects.

I started with the simple convention of jobname-containername since it
is easy to integrate
with the infrastructure we already have in the project.

Nir
___
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/K46FB3JIV6HALXJKC3MARNHDWHAXPG5K/

[ovirt-devel] Re: IPV6 on github actions container

[Nir Soffer]

On Wed, Dec 1, 2021 at 11:11 PM Nir Soffer  wrote:
>
> I'm trying to add a github action workflow for ovirt-imageio.
>
> The yml file is simple:
> https://github.com/nirs/ovirt-imageio/commit/21da91274b7b4722167c2415d1c1b5db08c5e88b
>
> And all the jobs run, but tons of tests are failing:
> https://github.com/nirs/ovirt-imageio/actions/runs/1527728851

Solved by not using github "container" option. Instead, just run
docker manually like we did in travis.

https://github.com/nirs/ovirt-imageio/commit/6fb94e9423c1642af716e3327038835fc09d225c

Notes for others that my have the same issue:

docker run -it ...

fails in github action with:

"the input device is not a TTY"

Removing the "-it" options solves this problem. The output of the command
running in the container logged to stdout. I don't know why we always run
the container with -it.

So we have working github CI for ovirt-imageio:
https://github.com/nirs/ovirt-imageio/actions/runs/1528026365

Running tests on centos stream 8, centos stream 9, and fedora 34 in 4 minutes.

I think the only thing missing to move to github, is to build the rpms in a way
that can be used by OST.

Nir
___
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/7CSZL3PO3CCQK67S47DX2OKTIECNPDEV/

[ovirt-devel] IPV6 on github actions container

[Nir Soffer]

I'm trying to add a github action workflow for ovirt-imageio.

The yml file is simple:
https://github.com/nirs/ovirt-imageio/commit/21da91274b7b4722167c2415d1c1b5db08c5e88b

And all the jobs run, but tons of tests are failing:
https://github.com/nirs/ovirt-imageio/actions/runs/1527728851

The typical failure is:

2021-12-01T20:50:07.6424921Z address = ('::', 43001), timeout =

2021-12-01T20:50:07.6425749Z source_address = None
2021-12-01T20:50:07.6425985Z
2021-12-01T20:50:07.6426421Z def create_connection(address,
timeout=_GLOBAL_DEFAULT_TIMEOUT,
2021-12-01T20:50:07.6426954Z   source_address=None):
...
2021-12-01T20:50:07.6435579Z host, port = address
2021-12-01T20:50:07.6435942Z err = None
2021-12-01T20:50:07.6436563Z for res in getaddrinfo(host,
port, 0, SOCK_STREAM):
2021-12-01T20:50:07.6437402Z af, socktype, proto,
canonname, sa = res
2021-12-01T20:50:07.6437834Z sock = None
2021-12-01T20:50:07.6438146Z try:
2021-12-01T20:50:07.6438522Z sock = socket(af, socktype, proto)
2021-12-01T20:50:07.6439032Z if timeout is not
_GLOBAL_DEFAULT_TIMEOUT:
2021-12-01T20:50:07.6439538Z sock.settimeout(timeout)
2021-12-01T20:50:07.6440109Z if source_address:
2021-12-01T20:50:07.6440522Z sock.bind(source_address)
2021-12-01T20:50:07.6440916Z >   sock.connect(sa)
2021-12-01T20:50:07.6441573Z E   OSError: [Errno 99]
Cannot assign requested address

I guess that ipv6 is disabled, and google confirms that github actions
and ipv6 is
an issue.

In travis we enabled ipv6 in docker using this script:
https://github.com/oVirt/ovirt-imageio/blob/master/travis/configure-docker.py

Run before starting the job:
https://github.com/oVirt/ovirt-imageio/blob/61f023bf1e45da4e98593278451030f433080ab0/.travis.yml#L15

I did not try to run this script yet, since I'm not sure we have a way
to run stuff *before*
the container runs in github actions.

I hope someone has some insight on a way to solve this.

Nir
___
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/467GFY5UP67PTCRNTHZWWIHA3H5YRIZ7/

[ovirt-devel] Re: oVirt Community - open discussion around repositories and workflows

[Nir Soffer]

On Wed, Dec 1, 2021 at 11:38 AM Milan Zamazal  wrote:
>
> Michal Skrivanek  writes:
>
> > Hi all,
> > so far we haven't encounter any blocking issue with this effort, I
> > wanted to propose to decide on oVirt development moving to GitHub,
> > COPR and CBS. Recent issue with decommissioning of our CI datacenter
> > is a good reminder why we are doing that...
> > What do we want to do?
> > 1) move "ovirt-master-snapshot" compose to COPR
> >   it is feasible for all projects except ovirt-node and
> > appliance due to COPR limitations, for these two we plan to use a
> > self-hosted runner in github env.
> >   it replaces the "build-artifacts" stdci stage
> > 2) move release to CentOS Community Build System to simplify our oVirt 
> > releases
> >   replaces our custom releng-tools process and aligns us better
> > with CentOS that is our main (and only) platform we support.
> > 3) move development from Gerrit to GitHub
> >   this is a very visible change and affects every oVirt
> > developer. We need a way how to test posted patches and the current
> > stdci "check-patch" stage is overly complex and slow to run, we lack
> > people for stdci maintenance in general (bluntly, it's a dead
> > project). Out of the various options that exist we ended up converging
> > to Github. Why? Just because it's the most simple thing to do for us,
> > with least amount of effort, least amount of additional people and hw
> > resources, with a manageable learning curve. It comes at a price - it
> > only works if we switch our primary development from Gerrit to Github
> > for all the remaining projects. It is a big change to our processes,
> > but I believe we have to go through that transition in order to solve
> > our CI troubles for good.  We started preparing guide and templates to
> > use so that we keep a uniform "look and feel" for all sub-projects, is
> > shall be ready soon.
> >
> > I'd like us to move from "POC" stage to "production", and actively
> > start working on the above, start moving project after project.
> > Let me ask for a final round of thoughts, comments, objections, we are 
> > ready to go ahead.
>
> Hi,
>
> the Vdsm maintainers have discussed the possibility of moving Vdsm
> development to GitHub and we consider it a reasonable and feasible
> option.  Although GitHub is not on par with Gerrit as for code reviews,
> having a more reliable common development platform outweighs the
> disadvantages.  There is already an ongoing work on having a fully
> usable Vdsm CI on GitHub.
>
> One thing related to the move is that we would like to retain the
> history of code reviews from Gerrit.  The comments there contain
> valuable information that we wouldn't like to lose.  Is there a way to
> export the public Gerrit contents, once we make a switch to GitHub for
> each particular project, to something that could be reasonably used for
> patch archaeology when needed?

I think keeping a readonly instance would be best, one all projects
migrated to github.

I hope there is a way to export the data to static html so it will be
available forever without running an actual gerrit instance.

Nir

>
> > It's not going to be easy, but I firmly believe it will greatly
> > improve maintainability of oVirt and reduce overhead that we all
> > struggle with for years.
> >
> > Thanks,
> > michal
> >
> >> On 10. 11. 2021, at 9:17, Sandro Bonazzola  wrote:
> >>
> >> Hi, here's an update on what has been done so far and how it is going.
> >>
> >> COPR
> >> All the oVirt active subprojects are now built on COPR except oVirt
> >> Engine Appliance and oVirt Node: I'm still looking into how to build
> >> them on COPR.
> >>
> >> Of those subprojects only the following are not yet built
> >> automatically on patch merge event as they have pending patches for
> >> enabling the automation:
> >> - ovirt-engine-nodejs-modules:
> >> https://gerrit.ovirt.org/c/ovirt-engine-nodejs-modules/+/117506
> >> -
> >> ovirt-engine-ui-extensions:
> >> https://gerrit.ovirt.org/c/ovirt-engine-ui-extensions/+/117512
> >> 
> >> - ovirt-web-ui: https://github.com/oVirt/ovirt-web-ui/pull/1532
> >> 
> >>
> >> You can see the build status for the whole project here:
> >> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/monitor/
> >> 
> >> If you are maintaining an oVirt project and you want to enable
> >> builds for CentOS Stream 9 or other architectures supported by copr
> >> please let me know.
> >>
> >> So far, the COPR infrastructure seems reliable and working well.
> >>
> >> GitHub
> >> The following projects are developed on GitHub only:
> >> - ovirt-ansible-collection
> >> - ovirt-cockpit-sso
> >> - ovirt-web-ui
> >> - python-ovirt-engine-sdk4
> >> - ovirt-engine-sdk-go

[ovirt-devel] Re: oVirt Community - open discussion around repositories and workflows

[Nir Soffer]

On Wed, Dec 1, 2021 at 11:11 AM Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

> Hi all,
> so far we haven't encounter any blocking issue with this effort, I wanted
> to propose to decide on oVirt development moving  to GitHub, COPR and CBS.
> Recent issue with decommissioning of our CI datacenter is a good reminder
> why we are doing that...
> What do we want to do?
> 1) move "ovirt-master-snapshot" compose to COPR
> it is feasible for all projects except ovirt-node and appliance due to
> COPR limitations, for these two we plan to use a self-hosted runner in
> github env.
> it replaces the "build-artifacts" stdci stage
> 2) move release to CentOS Community Build System to simplify our oVirt
> releases
> replaces our custom releng-tools process and aligns us better with CentOS
> that is our main (and only) platform we support.
> 3) move development from Gerrit to GitHub
> this is a very visible change and affects every oVirt developer. We need a
> way how to test posted patches and the current stdci "check-patch" stage is
> overly complex and slow to run, we lack people for stdci maintenance in
> general (bluntly, it's a dead project). Out of the various options that
> exist we ended up converging to Github. Why? Just because it's the most
> simple thing to do for us, with least amount of effort, least amount of
> additional people and hw resources, with a manageable learning curve. It
> comes at a price - it only works if we switch our primary development from
> Gerrit to Github for all the remaining projects. It is a big change to our
> processes, but I believe we have to go through that transition in order to
> solve our CI troubles for good.  We started preparing guide and templates
> to use so that we keep a uniform "look and feel" for all sub-projects, is
> shall be ready soon.
>
> I'd like us to move from "POC" stage to "production", and actively start
> working on the above, start moving project after project.
> Let me ask for a final round of thoughts, comments, objections, we are
> ready to go ahead.
>
> It's not going to be easy, but I firmly believe it will greatly improve
> maintainability of oVirt and reduce overhead that we all struggle with for
> years.
>

This is actually pretty easy. We start to work on this last week, and we
have
partial CI in place on github and gitlab.

- lint: merged!
https://github.com/oVirt/vdsm/actions/runs/1526187734

- storage tests:
https://gerrit.ovirt.org/c/vdsm/+/117882/
https://github.com/oVirt/vdsm/actions/runs/1526489399

We don't accept pull requests on github yet, but you can open
pull request for testing, like this:
https://github.com/oVirt/vdsm/pull/25
The new CI runs for the pull request.

I also added the same CI pipeline to gitlab:
https://gitlab.com/nirs/vdsm/-/pipelines/420340180

This will help to avoid locking to github, or backup if github has
an outage (just happened last week).

The new CI is based on containers, and should be usable locally
using podman, see:
https://github.com/oVirt/vdsm/blob/master/tests/start-container

The only thing missing to move to github is a way to trigger OST
and add OST results when it is done.

Nir


> Thanks,
> michal
>
> On 10. 11. 2021, at 9:17, Sandro Bonazzola  wrote:
>
> Hi, here's an update on what has been done so far and how it is going.
>
> *COPR*
> All the oVirt active subprojects are now built on COPR except oVirt Engine
> Appliance and oVirt Node: I'm still looking into how to build them on COPR.
>
> Of those subprojects only the following are not yet built automatically on
> patch merge event as they have pending patches for enabling the automation:
> - ovirt-engine-nodejs-modules:
> https://gerrit.ovirt.org/c/ovirt-engine-nodejs-modules/+/117506
> - ovirt-engine-ui-extensions:
> https://gerrit.ovirt.org/c/ovirt-engine-ui-extensions/+/117512
> - ovirt-web-ui: https://github.com/oVirt/ovirt-web-ui/pull/1532
>
> You can see the build status for the whole project here:
> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/monitor/
> If you are maintaining an oVirt project and you want to enable builds for
> CentOS Stream 9 or other architectures supported by copr please let me know.
>
> So far, the COPR infrastructure seems reliable and working well.
>
> *GitHub*
> The following projects are developed on GitHub only:
> - ovirt-ansible-collection
> - ovirt-cockpit-sso
> - ovirt-web-ui
> - python-ovirt-engine-sdk4
> - ovirt-engine-sdk-go
>
> Within this list:
> - ovirt-engine-sdk-go is not being built in COPR as the rpm is not needed
> for developing with go and the automation is already handled on GitHub
> actions only.
> - ovirt-cockpit-sso is still triggering jenkins jobs but it's ready to
> drop them as PR are now tested with github actions too and builds are
> handled in COPR.
>
> So far, moving the development to GitHub only seems to be working well and
> I would suggest the maintainers of the oVirt subprojects to consider moving
> to GitHub only as well.
> +Sanja Bonic  

[ovirt-devel] Re: oVirt Dashpanel - see all open issues and PRs on GitHub

[Nir Soffer]

On Mon, Nov 29, 2021 at 3:12 PM Sanja Bonic  wrote:
>
> Hi everyone,
>
> In the ovirt-site repository, we now have an overview of all open issues and 
> PRs:
>
> https://github.com/oVirt/ovirt-site/blob/dashpanel/dashpanel-ovirt.md

Nice.

I think these changes are needed:

- Rename the strange "Dashpanel - oVirt" to "oVirt projects"

- Include all the projects in the list

- Link to every project entrypoint for contributing. I hope that all project
  will use github or gitlab soon, but for now most projects should link
  to gerrit.ovirt.org.

- The number of issues is not relevant for most projects since we don't
  use github issues, we really want to see the number of bugs from
  bugzilla.redhat.com.

> Archived and private repositories are excluded from this list. The .md is 
> linked from https://www.ovirt.org/community/ in the "Developers" section and 
> is updated automatically every day using GitHub Actions.

I think a better place for this content is here:
https://www.ovirt.org/develop/

This page has almost no useful content. Seeing the actual projects that
you can contribute to sounds useful.

Or include the top 10 active projects in /develop/ and link to the
full list.

Nir
___
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/7EEVGGWJRWROWAUSJPD2TTUPIA4REUQO/

[ovirt-devel] Re: GitHub Actions-based CI for vdsm

[Nir Soffer]

On Sun, Nov 28, 2021 at 3:44 PM Nir Soffer  wrote:
>
> On Sun, Nov 28, 2021 at 12:41 PM Nir Soffer  wrote:
> >
> > On Fri, Nov 26, 2021 at 7:44 PM Marcin Sobczyk  wrote:
> > >
> > > Hi All,
> > >
> > > I've been working on adding GitHub Actions-based CI to vdsm today.
> > > Feel free to check out the patches here:
> > >
> > > https://gerrit.ovirt.org/q/topic:%22github-actions-ci%22+(status:open%20OR%20status:merged)
> >
> > Awesome!
> >
> > > Some comments:
> > > - the linters work fine already, we can start using them
> > >
> > > - RPM building works too in general. I think the RPM versions are not
> > > right yet,
>
> rpm versions are corrected by:
> - pushing current master to your fork
> - pushing --tags to your fork
> - using "check-depth: 0" option for actions/checkout@v2
>
> >  so I'll look into this. After the 'rpm' job is done we get a
> > > zipfile with all the built RPMs inside. In the future we may want to run
> > > 'createrepo_c' on this dir as well, so we'll have a ready-to-be-used
> > > repository in that zip.
> >
> > We already have code to do this in automation/common.sh - can we
> > reuse it or extract it to new script?
> >
> > > - 'tests' are working too, but we have a couple of failures we'd need to
> > > look at. This job, unlike the others, runs in GitHub's Ubuntu VM inside
> > > which we use a privileged container for running the tests.
> >
> > The failure seems to be missing TRAVIS_CI=1 environment variable.
> > This should of course change to something moer generic like CONTAINER_CI=1
> > and the helper modules tests/testing.py should be updated.
>
> Tests pass adding
>
>env:
>  TRAVIS_CI=1
>
> Ugly but works :-)
>
> > > - didn't try 'tests-storage' yet
> >
> > That's fine, the storage team will handle this.
>
> Added storage tests here:
> https://github.com/nirs/vdsm/commit/0e5282945e4c86e65d5a1c12987e7534f350f2f2
>
> > > - Not to waist precious free CI minutes and storage, we run linters
> > > first, tests after that, but only under the condition that the linters
> > > didn't fail, and finally we build RPMs, but this time under the
> > > condition that the tests didn't fail.
> >
> > This is very bad idea. We want to run all the jobs in parallel so we
> > can get quick feedback from all jobs at the same run. There is no real
> > dependency between the jobs, and we don't waste resources by running
> > them in parallel.
>
> Here is a build with all jobs running in parallel, finish in 6.5 minutes:
> https://github.com/nirs/vdsm/actions/runs/1512754118
>
> I think we can add install tests to the rpm job.
>
> This is at least 3 times faster than jenkins.
>
> We can start using github CI now.

Here is also (much simpler) CI pipeline for gitlab:
https://gitlab.com/nirs/vdsm/-/commit/dfaaf8f7311501307e4269fc0b427417ff5264d3

It works, except 3 network tests that need privileged container:
https://gitlab.com/nirs/vdsm/-/pipelines/417881870

Network short summary:
= 1 failed, 310 passed, 32 skipped, 4 xfailed, 2 xpassed, 1 warning, 2
errors in 17.12s =

The long test (tests-storage) took 6 minutes, a little faster than github.

The lint job is slower (, since gitlab provides a VM with one core,
but our longest tests
(storage) are not cpu bound, so it does not matter.

The rpm job creates rpms correctly without jumping through any hoops:
https://gitlab.com/nirs/vdsm/-/jobs/1826841070

Looks like both github and gitlab gives us better CI with very little effort.

Nir
___
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/U7ALQN3A4PGHRHROAHDV5PKDYNPOEQJM/

[ovirt-devel] Re: GitHub Actions-based CI for vdsm

[Nir Soffer]

On Sun, Nov 28, 2021 at 12:41 PM Nir Soffer  wrote:
>
> On Fri, Nov 26, 2021 at 7:44 PM Marcin Sobczyk  wrote:
> >
> > Hi All,
> >
> > I've been working on adding GitHub Actions-based CI to vdsm today.
> > Feel free to check out the patches here:
> >
> > https://gerrit.ovirt.org/q/topic:%22github-actions-ci%22+(status:open%20OR%20status:merged)
>
> Awesome!
>
> > Some comments:
> > - the linters work fine already, we can start using them
> >
> > - RPM building works too in general. I think the RPM versions are not
> > right yet,

rpm versions are corrected by:
- pushing current master to your fork
- pushing --tags to your fork
- using "check-depth: 0" option for actions/checkout@v2

>  so I'll look into this. After the 'rpm' job is done we get a
> > zipfile with all the built RPMs inside. In the future we may want to run
> > 'createrepo_c' on this dir as well, so we'll have a ready-to-be-used
> > repository in that zip.
>
> We already have code to do this in automation/common.sh - can we
> reuse it or extract it to new script?
>
> > - 'tests' are working too, but we have a couple of failures we'd need to
> > look at. This job, unlike the others, runs in GitHub's Ubuntu VM inside
> > which we use a privileged container for running the tests.
>
> The failure seems to be missing TRAVIS_CI=1 environment variable.
> This should of course change to something moer generic like CONTAINER_CI=1
> and the helper modules tests/testing.py should be updated.

Tests pass adding

   env:
 TRAVIS_CI=1

Ugly but works :-)

> > - didn't try 'tests-storage' yet
>
> That's fine, the storage team will handle this.

Added storage tests here:
https://github.com/nirs/vdsm/commit/0e5282945e4c86e65d5a1c12987e7534f350f2f2

> > - Not to waist precious free CI minutes and storage, we run linters
> > first, tests after that, but only under the condition that the linters
> > didn't fail, and finally we build RPMs, but this time under the
> > condition that the tests didn't fail.
>
> This is very bad idea. We want to run all the jobs in parallel so we
> can get quick feedback from all jobs at the same run. There is no real
> dependency between the jobs, and we don't waste resources by running
> them in parallel.

Here is a build with all jobs running in parallel, finish in 6.5 minutes:
https://github.com/nirs/vdsm/actions/runs/1512754118

I think we can add install tests to the rpm job.

This is at least 3 times faster than jenkins.

We can start using github CI now.
___
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/6OJMLXJRLZXT3QJ4IVTVIDEWKJ3UDNMU/

[ovirt-devel] Re: GitHub Actions-based CI for vdsm

[Nir Soffer]

On Fri, Nov 26, 2021 at 7:44 PM Marcin Sobczyk  wrote:
>
> Hi All,
>
> I've been working on adding GitHub Actions-based CI to vdsm today.
> Feel free to check out the patches here:
>
> https://gerrit.ovirt.org/q/topic:%22github-actions-ci%22+(status:open%20OR%20status:merged)

Awesome!

> Some comments:
> - the linters work fine already, we can start using them
>
> - RPM building works too in general. I think the RPM versions are not
> right yet, so I'll look into this. After the 'rpm' job is done we get a
> zipfile with all the built RPMs inside. In the future we may want to run
> 'createrepo_c' on this dir as well, so we'll have a ready-to-be-used
> repository in that zip.

We already have code to do this in automation/common.sh - can we
reuse it or extract it to new script?

> - 'tests' are working too, but we have a couple of failures we'd need to
> look at. This job, unlike the others, runs in GitHub's Ubuntu VM inside
> which we use a privileged container for running the tests.

The failure seems to be missing TRAVIS_CI=1 environment variable.
This should of course change to something moer generic like CONTAINER_CI=1
and the helper modules tests/testing.py should be updated.

> - didn't try 'tests-storage' yet

That's fine, the storage team will handle this.

> - Not to waist precious free CI minutes and storage, we run linters
> first, tests after that, but only under the condition that the linters
> didn't fail, and finally we build RPMs, but this time under the
> condition that the tests didn't fail.

This is very bad idea. We want to run all the jobs in parallel so we
can get quick feedback from all jobs at the same run. There is no real
dependency between the jobs, and we don't waste resources by running
them in parallel.

Thanks for this work!

Nir
___
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/7Z7CY63OWHKRL32V4BULA2I43LBIOQFG/

[ovirt-devel] Re: CI failing all the time

[Nir Soffer]

On Sun, Nov 28, 2021 at 10:59 AM Nir Soffer  wrote:
>
> On Fri, Nov 26, 2021 at 12:57 PM Ehud Yonasi  wrote:
> >
> > Hi Nir,
> >
> > There was a problem in jenkins to switch to the new k8s stack on IBM cloud, 
> > a restart was required and now it’s solved.
>
> The queue is increasing again, currently 12 jobs in the queue:
>
> Build Queue (12)
> system-mk_mirrors_index-yum
> part of vdsm_standard-check-patch #31073 vdsm [check-patch]
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> part of jenkins_standard-check-patch #5550
> part of jenkins_standard-check-patch #5548
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> part of ovirt-appliance_standard-check-patch #385 ovirt-appliance
> [check-patch]
> lago-demo_master_github_timed-el7-x86_64

Queue size is 24 now

Build Queue (24)
ovirt-engine_standard-on-merge
ovirt-engine_standard-on-merge
standard-enqueue
standard-enqueue
ovirt-engine_standard-on-merge
standard-enqueue
ovirt-engine_standard-on-merge
standard-enqueue
part of ovirt-engine_standard-check-patch #15338
part of ovirt-engine_standard-check-patch #15337
part of ovirt-engine_standard-check-patch #15336
part of ovirt-engine_standard-check-patch #15335
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
part of jenkins_standard-check-patch #5550
part of jenkins_standard-check-patch #5548
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
part of ovirt-appliance_standard-check-patch #385 ovirt-appliance
[check-patch]
lago-demo_master_github_timed-el7-x86_64
part of ovirt-engine_standard-on-merge #2664
part of ovirt-engine_standard-check-patch #15334

>
>
> >
> >
> > On 25 Nov 2021, at 21:53, Nir Soffer  wrote:
> >
> > On Thu, Nov 25, 2021 at 9:15 PM Michal Skrivanek
> >  wrote:
> >
> >
> >
> >
> > On 25. 11. 2021, at 16:45, Evgheni Dereveanchin  wrote:
> >
> > Hi Milan,
> >
> > Indeed, this is related to the Jenkins move: all pre-existing nodes are no 
> > longer usable so new ones have been created.
> > We're looking into the reasons new nodes fail to initialize and bringing up 
> > new ones in parallel to help with processing the build queue.
> >
> > Sorry for the inconvenience. Please report any other issues if you see them 
> > as there may be quite some instability due to the rebuild.
> >
> >
> > Hi Evgheni,
> > the queue is now 53 builds long, and it seems nothing is building, perhaps 
> > there's no worker or the labelling is wrong?
> >
> >
> > Looks like jobs are stuck for several hours
> > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31036/
> >
> > at the "loading code" stage:
> > https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31036/pipeline
> >
> > With this error:
> >
> >There are no nodes with the label 
> > ‘jenkins-vdsm_standard-check-patch-31036’
> >
> > The label looks wrong. vdsm requires nodes with "el8" label.
> >
> >
> > Thanks,
> > michal
> >
> >
> > Regards.
> > Evgheni
> >
> > On Thu, Nov 25, 2021 at 4:24 PM Nir Soffer  wrote:
> >
> >
> > On Thu, Nov 25, 2021 at 3:48 PM Milan Zamazal  wrote:
> >
> >
> > Hi,
> >
> > all patches uploaded today I've seen (for Engine and Vdsm) fail due to
> > problems with availability of packages when preparing the el7
> > environment.  For example:
> > https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15291/
> >
> > Additionally, Vdsm tests are not run on PSI.
> >
> > Does anybody know what's wrong and how to fix it?  Can it be related to
> > the Jenkins move?
> >
> >
> > Looking at
> > https://jenkins.ovirt.org/
> >
> > There are 33 jobs in the queue, and only 3 jobs running.
> >
> > Maybe we did not restore all the nodes?
> >
> >
> > ___
> > 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/ZLH3ILKHC3YPZWQFA2SG4GS3QSIALUXZ/
>

[ovirt-devel] Re: CI failing all the time

[Nir Soffer]

On Sun, Nov 28, 2021 at 11:35 AM Nir Soffer  wrote:
>
> On Sun, Nov 28, 2021 at 10:59 AM Nir Soffer  wrote:
> >
> > On Fri, Nov 26, 2021 at 12:57 PM Ehud Yonasi  wrote:
> > >
> > > Hi Nir,
> > >
> > > There was a problem in jenkins to switch to the new k8s stack on IBM 
> > > cloud, a restart was required and now it’s solved.
> >
> > The queue is increasing again, currently 12 jobs in the queue:
>
> Vdsm jobs requires el8 nodes, but we have only one:
> https://jenkins.ovirt.org/label/el8/
>
> we also have only one el9stream node:
> https://jenkins.ovirt.org/label/el9stream/
>
> I posted this to use all nodes in vdsm, instead of only the el8 nodes:
> https://gerrit.ovirt.org/c/vdsm/+/117826
>
> It did not work in the old data center, but maybe the issue with  the 
> el9stream
> nodes is solved now.

It does not work yet, el9stream fails quickly in global_setup.sh:

[2021-11-28T09:35:20.829Z] + sudo -n systemctl start libvirtd haveged firewalld
[2021-11-28T09:35:21.086Z] Failed to start libvirtd.service: Unit
libvirtd.service not found.
[2021-11-28T09:35:21.086Z] Failed to start haveged.service: Unit
haveged.service not found.

See https://ovirt-jira.atlassian.net/browse/OVIRT-3126

>
> >
> > Build Queue (12)
> > system-mk_mirrors_index-yum
> > part of vdsm_standard-check-patch #31073 vdsm [check-patch]
> > jenkins_master_check-patch-el7-ppc64le
> > jenkins_master_check-patch-el7-ppc64le
> > part of jenkins_standard-check-patch #5550
> > part of jenkins_standard-check-patch #5548
> > jenkins_master_check-patch-el7-ppc64le
> > jenkins_master_check-patch-el7-ppc64le
> > jenkins_master_check-patch-el7-ppc64le
> > jenkins_master_check-patch-el7-ppc64le
> > part of ovirt-appliance_standard-check-patch #385 ovirt-appliance
> > [check-patch]
> > lago-demo_master_github_timed-el7-x86_64
> >
> >
> > >
> > >
> > > On 25 Nov 2021, at 21:53, Nir Soffer  wrote:
> > >
> > > On Thu, Nov 25, 2021 at 9:15 PM Michal Skrivanek
> > >  wrote:
> > >
> > >
> > >
> > >
> > > On 25. 11. 2021, at 16:45, Evgheni Dereveanchin  
> > > wrote:
> > >
> > > Hi Milan,
> > >
> > > Indeed, this is related to the Jenkins move: all pre-existing nodes are 
> > > no longer usable so new ones have been created.
> > > We're looking into the reasons new nodes fail to initialize and bringing 
> > > up new ones in parallel to help with processing the build queue.
> > >
> > > Sorry for the inconvenience. Please report any other issues if you see 
> > > them as there may be quite some instability due to the rebuild.
> > >
> > >
> > > Hi Evgheni,
> > > the queue is now 53 builds long, and it seems nothing is building, 
> > > perhaps there's no worker or the labelling is wrong?
> > >
> > >
> > > Looks like jobs are stuck for several hours
> > > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31036/
> > >
> > > at the "loading code" stage:
> > > https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31036/pipeline
> > >
> > > With this error:
> > >
> > >There are no nodes with the label 
> > > ‘jenkins-vdsm_standard-check-patch-31036’
> > >
> > > The label looks wrong. vdsm requires nodes with "el8" label.
> > >
> > >
> > > Thanks,
> > > michal
> > >
> > >
> > > Regards.
> > > Evgheni
> > >
> > > On Thu, Nov 25, 2021 at 4:24 PM Nir Soffer  wrote:
> > >
> > >
> > > On Thu, Nov 25, 2021 at 3:48 PM Milan Zamazal  wrote:
> > >
> > >
> > > Hi,
> > >
> > > all patches uploaded today I've seen (for Engine and Vdsm) fail due to
> > > problems with availability of packages when preparing the el7
> > > environment.  For example:
> > > https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15291/
> > >
> > > Additionally, Vdsm tests are not run on PSI.
> > >
> > > Does anybody know what's wrong and how to fix it?  Can it be related to
> > > the Jenkins move?
> > >
> > >
> > > Looking at
> > > https://jenkins.ovirt.org/
> > >
> > > There are 33 jobs in the queue, and only 3 jobs running.
> > >
> > > Maybe we did not restore all the nodes

[ovirt-devel] Re: CI failing all the time

[Nir Soffer]

On Sun, Nov 28, 2021 at 10:59 AM Nir Soffer  wrote:
>
> On Fri, Nov 26, 2021 at 12:57 PM Ehud Yonasi  wrote:
> >
> > Hi Nir,
> >
> > There was a problem in jenkins to switch to the new k8s stack on IBM cloud, 
> > a restart was required and now it’s solved.
>
> The queue is increasing again, currently 12 jobs in the queue:

Vdsm jobs requires el8 nodes, but we have only one:
https://jenkins.ovirt.org/label/el8/

we also have only one el9stream node:
https://jenkins.ovirt.org/label/el9stream/

I posted this to use all nodes in vdsm, instead of only the el8 nodes:
https://gerrit.ovirt.org/c/vdsm/+/117826

It did not work in the old data center, but maybe the issue with  the el9stream
nodes is solved now.

>
> Build Queue (12)
> system-mk_mirrors_index-yum
> part of vdsm_standard-check-patch #31073 vdsm [check-patch]
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> part of jenkins_standard-check-patch #5550
> part of jenkins_standard-check-patch #5548
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> jenkins_master_check-patch-el7-ppc64le
> part of ovirt-appliance_standard-check-patch #385 ovirt-appliance
> [check-patch]
> lago-demo_master_github_timed-el7-x86_64
>
>
> >
> >
> > On 25 Nov 2021, at 21:53, Nir Soffer  wrote:
> >
> > On Thu, Nov 25, 2021 at 9:15 PM Michal Skrivanek
> >  wrote:
> >
> >
> >
> >
> > On 25. 11. 2021, at 16:45, Evgheni Dereveanchin  wrote:
> >
> > Hi Milan,
> >
> > Indeed, this is related to the Jenkins move: all pre-existing nodes are no 
> > longer usable so new ones have been created.
> > We're looking into the reasons new nodes fail to initialize and bringing up 
> > new ones in parallel to help with processing the build queue.
> >
> > Sorry for the inconvenience. Please report any other issues if you see them 
> > as there may be quite some instability due to the rebuild.
> >
> >
> > Hi Evgheni,
> > the queue is now 53 builds long, and it seems nothing is building, perhaps 
> > there's no worker or the labelling is wrong?
> >
> >
> > Looks like jobs are stuck for several hours
> > https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31036/
> >
> > at the "loading code" stage:
> > https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31036/pipeline
> >
> > With this error:
> >
> >There are no nodes with the label 
> > ‘jenkins-vdsm_standard-check-patch-31036’
> >
> > The label looks wrong. vdsm requires nodes with "el8" label.
> >
> >
> > Thanks,
> > michal
> >
> >
> > Regards.
> > Evgheni
> >
> > On Thu, Nov 25, 2021 at 4:24 PM Nir Soffer  wrote:
> >
> >
> > On Thu, Nov 25, 2021 at 3:48 PM Milan Zamazal  wrote:
> >
> >
> > Hi,
> >
> > all patches uploaded today I've seen (for Engine and Vdsm) fail due to
> > problems with availability of packages when preparing the el7
> > environment.  For example:
> > https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15291/
> >
> > Additionally, Vdsm tests are not run on PSI.
> >
> > Does anybody know what's wrong and how to fix it?  Can it be related to
> > the Jenkins move?
> >
> >
> > Looking at
> > https://jenkins.ovirt.org/
> >
> > There are 33 jobs in the queue, and only 3 jobs running.
> >
> > Maybe we did not restore all the nodes?
> >
> >
> > ___
> > 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/ZLH3ILKHC3YPZWQFA2SG4GS3QSIALUXZ/
> >
> >
> > ___
> > 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/RZ7H4L26DU6LAKFQXJE4W3D4C5HP76CX/
> >
> > ___
> > Devel mailing list 

[ovirt-devel] Re: CI failing all the time

[Nir Soffer]

On Fri, Nov 26, 2021 at 12:57 PM Ehud Yonasi  wrote:
>
> Hi Nir,
>
> There was a problem in jenkins to switch to the new k8s stack on IBM cloud, a 
> restart was required and now it’s solved.

The queue is increasing again, currently 12 jobs in the queue:

Build Queue (12)
system-mk_mirrors_index-yum
part of vdsm_standard-check-patch #31073 vdsm [check-patch]
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
part of jenkins_standard-check-patch #5550
part of jenkins_standard-check-patch #5548
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
jenkins_master_check-patch-el7-ppc64le
part of ovirt-appliance_standard-check-patch #385 ovirt-appliance
[check-patch]
lago-demo_master_github_timed-el7-x86_64


>
>
> On 25 Nov 2021, at 21:53, Nir Soffer  wrote:
>
> On Thu, Nov 25, 2021 at 9:15 PM Michal Skrivanek
>  wrote:
>
>
>
>
> On 25. 11. 2021, at 16:45, Evgheni Dereveanchin  wrote:
>
> Hi Milan,
>
> Indeed, this is related to the Jenkins move: all pre-existing nodes are no 
> longer usable so new ones have been created.
> We're looking into the reasons new nodes fail to initialize and bringing up 
> new ones in parallel to help with processing the build queue.
>
> Sorry for the inconvenience. Please report any other issues if you see them 
> as there may be quite some instability due to the rebuild.
>
>
> Hi Evgheni,
> the queue is now 53 builds long, and it seems nothing is building, perhaps 
> there's no worker or the labelling is wrong?
>
>
> Looks like jobs are stuck for several hours
> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31036/
>
> at the "loading code" stage:
> https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31036/pipeline
>
> With this error:
>
>There are no nodes with the label ‘jenkins-vdsm_standard-check-patch-31036’
>
> The label looks wrong. vdsm requires nodes with "el8" label.
>
>
> Thanks,
> michal
>
>
> Regards.
> Evgheni
>
> On Thu, Nov 25, 2021 at 4:24 PM Nir Soffer  wrote:
>
>
> On Thu, Nov 25, 2021 at 3:48 PM Milan Zamazal  wrote:
>
>
> Hi,
>
> all patches uploaded today I've seen (for Engine and Vdsm) fail due to
> problems with availability of packages when preparing the el7
> environment.  For example:
> https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15291/
>
> Additionally, Vdsm tests are not run on PSI.
>
> Does anybody know what's wrong and how to fix it?  Can it be related to
> the Jenkins move?
>
>
> Looking at
> https://jenkins.ovirt.org/
>
> There are 33 jobs in the queue, and only 3 jobs running.
>
> Maybe we did not restore all the nodes?
>
>
> ___
> 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/ZLH3ILKHC3YPZWQFA2SG4GS3QSIALUXZ/
>
>
> ___
> 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/RZ7H4L26DU6LAKFQXJE4W3D4C5HP76CX/
>
> ___
> 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/UK4KVTPITCAWHWUR5QPGN3RSNFYQSH34/
>
>
___
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/MREDOKMNI4K5RYQ24ASWNYHGJML2QCFI/

[ovirt-devel] Build artifacts jobs always fail - OST cannot run

[Nir Soffer]

Since last week, all build artifacts jobs fail with "Testing system error":
- 
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31062/artifact/ci_build_summary.html
- 
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31064/artifact/ci_build_summary.html
- 
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31063/artifact/ci_build_summary.html

This breaks OST, waiting for the builds.

The error seems to be in global_setup.sh:

[2021-11-26T16:02:21.443Z] + sudo -n systemctl start libvirtd haveged firewalld
[2021-11-26T16:02:21.443Z] Failed to start libvirtd.service: Unit not found.
[2021-11-26T16:02:21.443Z] Failed to start haveged.service: Unit not found.

Nir
___
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/524XMJFJTGIQTJILQQGDE4JZ4NWOMFT6/

[ovirt-devel] Re: CI failing all the time

[Nir Soffer]

On Thu, Nov 25, 2021 at 9:15 PM Michal Skrivanek
 wrote:
>
>
>
> On 25. 11. 2021, at 16:45, Evgheni Dereveanchin  wrote:
>
> Hi Milan,
>
> Indeed, this is related to the Jenkins move: all pre-existing nodes are no 
> longer usable so new ones have been created.
> We're looking into the reasons new nodes fail to initialize and bringing up 
> new ones in parallel to help with processing the build queue.
>
> Sorry for the inconvenience. Please report any other issues if you see them 
> as there may be quite some instability due to the rebuild.
>
>
> Hi Evgheni,
> the queue is now 53 builds long, and it seems nothing is building, perhaps 
> there's no worker or the labelling is wrong?

Looks like jobs are stuck for several hours
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31036/

at the "loading code" stage:
https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/31036/pipeline

With this error:

There are no nodes with the label ‘jenkins-vdsm_standard-check-patch-31036’

The label looks wrong. vdsm requires nodes with "el8" label.

>
> Thanks,
> michal
>
>
> Regards.
> Evgheni
>
> On Thu, Nov 25, 2021 at 4:24 PM Nir Soffer  wrote:
>>
>> On Thu, Nov 25, 2021 at 3:48 PM Milan Zamazal  wrote:
>> >
>> > Hi,
>> >
>> > all patches uploaded today I've seen (for Engine and Vdsm) fail due to
>> > problems with availability of packages when preparing the el7
>> > environment.  For example:
>> > https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15291/
>> >
>> > Additionally, Vdsm tests are not run on PSI.
>> >
>> > Does anybody know what's wrong and how to fix it?  Can it be related to
>> > the Jenkins move?
>>
>> Looking at
>> https://jenkins.ovirt.org/
>>
>> There are 33 jobs in the queue, and only 3 jobs running.
>>
>> Maybe we did not restore all the nodes?
>>
>
> ___
> 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/ZLH3ILKHC3YPZWQFA2SG4GS3QSIALUXZ/
>
>
> ___
> 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/RZ7H4L26DU6LAKFQXJE4W3D4C5HP76CX/
___
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/UK4KVTPITCAWHWUR5QPGN3RSNFYQSH34/

[ovirt-devel] Re: CI failing all the time

[Nir Soffer]

On Thu, Nov 25, 2021 at 3:48 PM Milan Zamazal  wrote:
>
> Hi,
>
> all patches uploaded today I've seen (for Engine and Vdsm) fail due to
> problems with availability of packages when preparing the el7
> environment.  For example:
> https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15291/
>
> Additionally, Vdsm tests are not run on PSI.
>
> Does anybody know what's wrong and how to fix it?  Can it be related to
> the Jenkins move?

Looking at
https://jenkins.ovirt.org/

There are 33 jobs in the queue, and only 3 jobs running.

Maybe we did not restore all the nodes?
___
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/J72NKWHRPW7JXYN6DRUTLCTGKAOYHBWG/

[ovirt-devel] Gerrit https links broken (since server was moved?)

[Nir Soffer]

Trying to "git pull" from gerrit get stuck now.

Checking https://gerrit.ovirt.org/admin/repos/vdsm
we see:

git clone "https://gerrit.ovirt.org/vdsm;

But visiting this url shows:

$ curl -i https://gerrit.ovirt.org/vdsm
HTTP/1.1 404 Not Found
Date: Thu, 25 Nov 2021 12:12:17 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips
Content-Type: text/plain;charset=iso-8859-1
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Content-Length: 9

Not Found

Same for ovirt-engine:

$ curl -i https://gerrit.ovirt.org/ovirt-engine
HTTP/1.1 404 Not Found
Date: Thu, 25 Nov 2021 12:13:13 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips
Content-Type: text/plain;charset=iso-8859-1
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Content-Length: 9

Not Found

I guess this is related to moving to new hardware yesterday?

Nir
___
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/VJ4HZNZTHDPYW2ZAMU5PMEUUU2I3C4PJ/

[ovirt-devel] Re: [VDSM] Warning: vdsm CI fails, looks like lvm regression in 8.6/stream

[Nir Soffer]

‫ב-22 בנוב׳ 2021, בשעה 15:58, ‏‏Nir Soffer ‏ כתב/ה:‬
> 
> On Mon, Nov 22, 2021 at 3:36 PM Nir Soffer  wrote:
>> 
>>> On Mon, Nov 22, 2021 at 3:23 PM Nir Soffer  wrote:
>>> 
>>> All vdsm CI runs fails now due to:
>>> https://bugzilla.redhat.com/2025527
>>> 
>>> Looks like leftover configuration (locking_type=4) from rhel 7 that
>>> was useless but harmless
>>> on rhel 8 is harmful now, converted by lvm to --readonly, which breaks
>>> lvchange --refresh.
>>> 
>>> So far seen only in vdsm CI, using Centos Stream. It is likely to
>>> break also on a real system
>>> using the same lvm version (unknown yet).
>>> 
>>> I posted this to log lvm version:
>>> https://gerrit.ovirt.org/c/vdsm/+/117741
>> 
>> Checking the code shows that this happens only when using read only mode - 
>> this
>> is leftover from rhel 7 and never used in rhel 8. The failure is only
>> in vdsm tests
>> testing read only mode.
> 
> This should unbreak the CI:
> https://gerrit.ovirt.org/c/vdsm/+/117743

Merged, please rebase to I’m real your CI.

> 
> More work is needed to remove the legacy read-only mode form lvm module.
> 
> Nir
___
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/P2JD2HZHQ5CAHQ56EN5ICZJTW3MQRHM2/

[ovirt-devel] Re: [VDSM] Warning: vdsm CI fails, looks like lvm regression in 8.6/stream

[Nir Soffer]

On Mon, Nov 22, 2021 at 3:36 PM Nir Soffer  wrote:
>
> On Mon, Nov 22, 2021 at 3:23 PM Nir Soffer  wrote:
> >
> > All vdsm CI runs fails now due to:
> > https://bugzilla.redhat.com/2025527
> >
> > Looks like leftover configuration (locking_type=4) from rhel 7 that
> > was useless but harmless
> > on rhel 8 is harmful now, converted by lvm to --readonly, which breaks
> > lvchange --refresh.
> >
> > So far seen only in vdsm CI, using Centos Stream. It is likely to
> > break also on a real system
> > using the same lvm version (unknown yet).
> >
> > I posted this to log lvm version:
> > https://gerrit.ovirt.org/c/vdsm/+/117741
>
> Checking the code shows that this happens only when using read only mode - 
> this
> is leftover from rhel 7 and never used in rhel 8. The failure is only
> in vdsm tests
> testing read only mode.

This should unbreak the CI:
https://gerrit.ovirt.org/c/vdsm/+/117743

More work is needed to remove the legacy read-only mode form lvm module.

Nir
___
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/5RWSPR34GPPJX7WX7MS5AGQIKRC4LN7E/

[ovirt-devel] Re: [VDSM] Warning: vdsm CI fails, looks like lvm regression in 8.6/stream

[Nir Soffer]

On Mon, Nov 22, 2021 at 3:23 PM Nir Soffer  wrote:
>
> All vdsm CI runs fails now due to:
> https://bugzilla.redhat.com/2025527
>
> Looks like leftover configuration (locking_type=4) from rhel 7 that
> was useless but harmless
> on rhel 8 is harmful now, converted by lvm to --readonly, which breaks
> lvchange --refresh.
>
> So far seen only in vdsm CI, using Centos Stream. It is likely to
> break also on a real system
> using the same lvm version (unknown yet).
>
> I posted this to log lvm version:
> https://gerrit.ovirt.org/c/vdsm/+/117741

Checking the code shows that this happens only when using read only mode - this
is leftover from rhel 7 and never used in rhel 8. The failure is only
in vdsm tests
testing read only mode.
___
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/GKJXDR656Y6ESWZQUKCGBSWM5OGN42DR/

[ovirt-devel] [VDSM] Warning: vdsm CI fails, looks like lvm regression in 8.6/stream

[Nir Soffer]

All vdsm CI runs fails now due to:
https://bugzilla.redhat.com/2025527

Looks like leftover configuration (locking_type=4) from rhel 7 that
was useless but harmless
on rhel 8 is harmful now, converted by lvm to --readonly, which breaks
lvchange --refresh.

So far seen only in vdsm CI, using Centos Stream. It is likely to
break also on a real system
using the same lvm version (unknown yet).

I posted this to log lvm version:
https://gerrit.ovirt.org/c/vdsm/+/117741

Nir
___
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/NWNKQMVXZHLVTFAPLAHQLM3CCXUBLP5G/

[ovirt-devel] Re: OST gating oddities

[Nir Soffer]

On Tue, Nov 16, 2021 at 9:43 PM Milan Zamazal  wrote:
>
> Hi,
>
> putting recently experienced problems with OST runs failures aside, I
> wonder about what currently happens in gerrit on gating.  For instance in
> https://gerrit.ovirt.org/c/vdsm/+/117523/6:
>
> - OST OST -1
>   Patch Set 6: OST-1
>   https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger1/4579 : Looking 
> for build artifacts for OST.
>   ci build
>
>   * Why setting OST-1 when looking for a build?
>
> - Jenkins CI
>   Patch Set 6:
>
>   No Builds Executed
>
>   https://jenkins.ovirt.org/job/vdsm_standard-check-patch/30672/ : To avoid 
> overloading the infrastructure, a whitelist for
>   running gerrit triggered jobs has been set in place, if
>   you feel like you should be in it, please contact infra at
>   ovirt dot org.
>
>   * OST not allowed to trigger builds?

This is caused by the same DNS issue. I see this in many builds:

[2021-11-18T16:38:43.034Z] error: RPC failed; result=6, HTTP code = 0
[2021-11-18T16:38:43.034Z] fatal: The remote end hung up unexpectedly
[2021-11-18T16:38:43.530Z] scripts/whitelist_filter.sh
[2021-11-18T16:38:43.530Z] Initialized empty Git repository in
/home/jenkins/agent/workspace/vdsm_standard-check-patch/jenkins-whitelist/.git/
[2021-11-18T16:38:43.530Z] Fetching whitelist repo from
https://gerrit.ovirt.org/jenkins-whitelist...
[2021-11-18T16:39:05.682Z] fatal: unable to access
'https://gerrit.ovirt.org/jenkins-whitelist/': Could not resolve host:
gerrit.ovirt.org; Unknown error
User nsof...@redhat.com is not whitelisted

Looks like the script fail to get clone the whitelist repo, and then
instead of failing
try to check if the current user is in the non-existing whitelist file.

>
> - OST OST +1
>   Patch Set 6: OST+1
>
>   https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger1/4583 : start OST 
> for https://jenkins.ovirt.org/job/vdsm_standard-check-patch/30681/
>
>   * Shouldn't OST set OST+1 after it runs rather than when it starts?
>
> Is there any explanation of these phenomenons?
>
> Thanks,
> Milan
> ___
> 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/IMRYKBROJXKU3EQAQYNQBJ67CJSXKWWD/
___
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/JN4DQL7NIWXRHU2VK366KM7VQAUACDCO/

[ovirt-devel] Re: OST gating oddities

[Nir Soffer]

On Tue, Nov 16, 2021 at 9:43 PM Milan Zamazal  wrote:
>
> Hi,
>
> putting recently experienced problems with OST runs failures aside, I
> wonder about what currently happens in gerrit on gating.  For instance in
> https://gerrit.ovirt.org/c/vdsm/+/117523/6:
>
> - OST OST -1
>   Patch Set 6: OST-1
>   https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger1/4579 : Looking 
> for build artifacts for OST.
>   ci build
>
>   * Why setting OST-1 when looking for a build?
>
> - Jenkins CI
>   Patch Set 6:
>
>   No Builds Executed
>
>   https://jenkins.ovirt.org/job/vdsm_standard-check-patch/30672/ : To avoid 
> overloading the infrastructure, a whitelist for
>   running gerrit triggered jobs has been set in place, if
>   you feel like you should be in it, please contact infra at
>   ovirt dot org.
>
>   * OST not allowed to trigger builds?
>
> - OST OST +1
>   Patch Set 6: OST+1
>
>   https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger1/4583 : start OST 
> for https://jenkins.ovirt.org/job/vdsm_standard-check-patch/30681/
>
>   * Shouldn't OST set OST+1 after it runs rather than when it starts?
>
> Is there any explanation of these phenomenons?

I have seen the same issues in the last week.

I think we should start moving the project to github or gitlab instead
of wasting time on fixing the legacy CI.

This is a good time to do this.

Nir
___
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/CF624PR42O5B5FBTWK6SWNZMWOQ2AAEM/

[ovirt-devel] Re: qemu-kvm 6.1.0 breaks hosted-engine

[Nir Soffer]

On Tue, Nov 16, 2021 at 12:28 PM Sandro Bonazzola 
wrote:

> +Eduardo Lima  and +Danilo Cesar Lemes de Paula
>   FYI
>
> Il giorno mar 16 nov 2021 alle ore 08:55 Yedidyah Bar David <
> d...@redhat.com> ha scritto:
>
>> Hi all,
>>
>> For a few days now we have failures in CI of the he-basic suite.
>>
>> At one point the failure seemed to have been around
>> networking/routing/firewalling, but later it changed, and now the
>> deploy process fails while trying to first start the engine vm after
>> it's copied to the shared storage.
>>
>> I ran locally OST he-basic with current ost-images, reproduced the
>> issue, and managed to "fix" it by enabling
>> ovirt-master-centos-stream-advanced-virtualization-testing and
>> downgrading qemu-kvm-* from 6.1.0 (from AppStream) to
>> 15:6.0.0-33.el8s.
>>
>> Is this a known issue?
>>
>> How do we handle? Perhaps we should conflict with it somewhere until
>> we find and fix the root cause.
>>
>> Please note that the flow is:
>>
>> 1. Create a local VM from the appliance image
>>
>
How do you create the vm?

Are you using libvirt? What is the VM XML used?


> 2. Do stuff on this machine
>> 3. Shut it down
>> 4. Copy its disk to shared storage
>> 5. Start the machine from the shared storage
>>
>
Just to be sure - step 1 - 4 works, but step 5 fails with qemu 6.1.0?


>
>> And that (1.) did work with 6.1.0, and also (5.) did work with 6.0.0
>> (so the copying (using qemu-img) did work well) and the difference is
>> elsewhere.
>>
>> Following is the diff between the qemu commands of (1.) and (5.) (as
>> found in the respective logs). Any clue?
>>
>> --- localq  2021-11-16 08:48:01.230426260 +0100
>> +++ sharedq 2021-11-16 08:48:46.884937598 +0100
>> @@ -1,54 +1,79 @@
>> -2021-11-14 15:09:56.430+: starting up libvirt version: 7.9.0,
>> package: 1.module_el8.6.0+983+a7505f3f (CentOS Buildsys
>> , 2021-11-09-20:38:08, ), qemu version:
>> 6.1.0qemu-kvm-6.1.0-4.module_el8.6.0+983+a7505f3f, kernel:
>> 4.18.0-348.el8.x86_64, hostname:
>> ost-he-basic-suite-master-host-0.lago.local
>> +2021-11-14 15:29:10.686+: starting up libvirt version: 7.9.0,
>> package: 1.module_el8.6.0+983+a7505f3f (CentOS Buildsys
>> , 2021-11-09-20:38:08, ), qemu version:
>> 6.1.0qemu-kvm-6.1.0-4.module_el8.6.0+983+a7505f3f, kernel:
>> 4.18.0-348.el8.x86_64, hostname:
>> ost-he-basic-suite-master-host-0.lago.local
>>  LC_ALL=C \
>>  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
>> -HOME=/var/lib/libvirt/qemu/domain-1-HostedEngineLocal \
>> -XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-1-HostedEngineLocal/.local/share
>> \
>> -XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-1-HostedEngineLocal/.cache \
>> -XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-1-HostedEngineLocal/.config
>> \
>> +HOME=/var/lib/libvirt/qemu/domain-2-HostedEngine \
>> +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-HostedEngine/.local/share \
>> +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-HostedEngine/.cache \
>> +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-HostedEngine/.config \
>>  /usr/libexec/qemu-kvm \
>> --name guest=HostedEngineLocal,debug-threads=on \
>> +-name guest=HostedEngine,debug-threads=on \
>>  -S \
>> --object
>> '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-HostedEngineLocal/master-key.aes"}'
>> \
>> --machine
>> pc-q35-rhel8.5.0,accel=kvm,usb=off,dump-guest-core=off,memory-backend=pc.ram
>> \
>> --cpu
>> Cascadelake-Server,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on,tsx-ctrl=on,hle=off,rtm=off,kvmclock=on
>> \
>> --m 3171 \
>> --object
>> '{"qom-type":"memory-backend-ram","id":"pc.ram","size":3325034496}' \
>> +-object
>> '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-2-HostedEngine/master-key.aes"}'
>> \
>> +-machine
>> pc-q35-rhel8.4.0,accel=kvm,usb=off,dump-guest-core=off,graphics=off \
>> +-cpu Cascadelake-Server-noTSX,mpx=off \
>> +-m size=3247104k,slots=16,maxmem=12988416k \
>>  -overcommit mem-lock=off \
>> --smp 2,sockets=2,cores=1,threads=1 \
>> --uuid 716b26d9-982b-4c51-ac05-646f28346007 \
>> +-smp 2,maxcpus=32,sockets=16,dies=1,cores=2,threads=1 \
>> +-object '{"qom-type":"iothread","id":"iothread1"}' \
>> +-object
>> '{"qom-type":"memory-backend-ram","id":"ram-node0","size":3325034496}'
>> \
>> +-numa node,nodeid=0,cpus=0-31,memdev=ram-node0 \
>> +-uuid a10f5518-1fc2-4aae-b7da-5d1d9875e753 \
>> +-smbios
>> type=1,manufacturer=oVirt,product=RHEL,version=8.6-1.el8,serial=d2f36f31-bb29-4e1f-b52d-8fddb632953c,uuid=a10f5518-1fc2-4aae-b7da-5d1d9875e753,family=oVirt
>> \
>>  -no-user-config \
>>  -nodefaults \
>>  -chardev socket,id=charmonitor,fd=40,server=on,wait=off \
>>  -mon chardev=charmonitor,id=monitor,mode=control \
>> --rtc base=utc \
>> +-rtc base=2021-11-14T15:29:08,driftfix=slew \
>> +-global 

[ovirt-devel] Re: OST: Vdsm: Occasional failures when stopping vdsmd

[Nir Soffer]

On Fri, Nov 12, 2021 at 9:15 PM Milan Zamazal  wrote:
>
> Hi,
>
> Michal has observed occasional OST failures in test_vdsm_recovery last
> days, which hadn't been seen before.  When `systemctl stop vdsmd' is
> called (via Ansible) there, vdsmd (almost?) never finishes its shutdown
> within the 10 seconds timeout and gets then killed with SIGKILL.  If
> this action is accompanied by "Job for vdsmd.service canceled." message
> then the test fails; otherwise OST continues normally.
>
> The situation is reproducible by running OST basic-suite-master and
> making it artificially failing after test_vdsm_recovery.  Then running
> `systemctl stop vdsmd' manually on the given OST host (can be done
> repeatedly, so it provides a good opportunity to examine the problem).
>
> There are two problems there:
>
> - "Job for vdsmd.service canceled." message that sometimes occurs after
>   `systemctl stop vdsmd' and then the test fails.  I don't know what it
>   means and I can't identify any difference in journal between when the
>   message occurs and when it doesn't.

This is likely caused by hosted engine agent discovering that hosted engine
storage domain was deactivated and panicking. systemd will try to restart
the hosted engine agent, and since it requires vdsm, systemd may start vdsm
while it is being shut down, and you will get this "canceled" message.

Basically if you want to stop vdsm you must stop other services requiring it
on the host.

If we want to avoid this craziness, we need to fix other services not to require
vdsm. It is not possible to manage a service when other services require it.

> - The fact that Vdsm doesn't stop within the timeout and must be killed.
>   This doesn't happen in my normal oVirt installation.  It apparently
>   blocks in self.irs.prepareForShutdown() call from clientIF.py.

This is normal in the last 7-8 years. Vdsm storage shutdown is broken
and is likely
to get stuck during shutdown. However, It never caused trouble in the past.

>   Journal says:
>
> systemd[1]: Stopping Virtual Desktop Server Manager...
> systemd[1]: vdsmd.service: State 'stop-sigterm' timed out. Killing.
> systemd[1]: vdsmd.service: Killing process 132608 (vdsmd) with signal 
> SIGKILL.
> systemd[1]: vdsmd.service: Killing process 133445 (ioprocess) with signal 
> SIGKILL.
> systemd[1]: vdsmd.service: Killing process 133446 (ioprocess) with signal 
> SIGKILL.
> systemd[1]: vdsmd.service: Killing process 133447 (ioprocess) with signal 
> SIGKILL.
> systemd[1]: vdsmd.service: Main process exited, code=killed, status=9/KILL
> systemd[1]: vdsmd.service: Failed with result 'timeout'.
> systemd[1]: Stopped Virtual Desktop Server Manager.
>
>   And vdsm.log (from a different run, sorry):
...
> 2021-11-12 07:09:32,820+ INFO  (MainThread) [storage.monitor] 
> Shutting down domain monitors (monitor:243)

This is shutdown flow - good...

> 2021-11-12 07:09:32,820+ INFO  (MainThread) [storage.monitor] Stop 
> monitoring 15fa3d6c-671b-46ef-af9a-00337011fa26 (shutdown=True) (monitor:268)

We stop the monitor with the shutdown flag - good...

> 2021-11-12 07:09:32,820+ INFO  (MainThread) [storage.monitor] Stop 
> monitoring a8bab4ef-2952-4c42-ba44-dbb3e1b8c87c (shutdown=True) (monitor:268)
...

> 2021-11-12 07:09:32,838+ INFO  (monitor/a8bab4e) [storage.check] Stop 
> checking 
> '/rhev/data-center/mnt/ost-he-basic-suite-master-storage:_exports_nfs_share1/a8bab4ef-2952-4c42-ba44-dbb3e1b8c87c/dom_md/metadata'
>  (check:135)

We stopped checking the domain - good...

> 2021-11-12 07:09:32,867+ INFO  (monitor/186180c) [storage.blocksd] 
> Tearing down domain 186180cb-5cc5-4aa4-868a-9e1ed7965ddf (blockSD:996)

Tearing down the storage domain - bad!

This is a bug that was hidden for several years since tearing down a
storage domain
did not really tear down the storage. Now that we really tear down the
storage, it will
deactivate logical volumes and remove device mapper devices.

> 2021-11-12 07:09:32,867+ DEBUG (monitor/186180c) [common.commands] 
> /usr/bin/taskset --cpu-list 0-1 /usr/bin/sudo -n /sbin/lvm vgchange --config 
> 'devices {  preferred_names=["^/dev/mapper/"]  ignore_suspended_devices=1  
> write_cache_state=0  disable_after_error_count=3  
> filter=["a|^/dev/mapper/36001405423a0b45cef54e6e9fd0c7df4$|^/dev/mapper/36001405e9302e3f55e74aedbf352b79f$|",
>  "r|.*|"]  hints="none"  obtain_device_list_from_udev=0 } global {  
> locking_type=1  prioritise_write_locks=1  wait_for_locks=1  use_lvmetad=0  
> use_lvmpolld=1 } backup {  retain_min=50  retain_days=0 }' --available n 
> 186180cb-5cc5-4aa4-868a-9e1ed7965ddf (cwd None) (commands:154)

This an attempt to deactivate a logical volume that should not happen
during shutdown...

> 2021-11-12 07:09:38,063+ DEBUG (monitor/186180c) [common.commands] 
> FAILED:  = b'  Logical volume 186180cb-5cc5-4aa4-868a-9e1ed7965ddf/ids 
> in use.\n  Can\'t deactivate volume group 
> 

[ovirt-devel] Re: Publishing oVirt Go modules under ovirt.org namespace

[Nir Soffer]

On Sat, Nov 6, 2021 at 1:53 AM Nir Soffer  wrote:
> > To make this work, the web server at ovirt.org should serve this resource:
> >
> > https://ovirt.org/imageio
> >
> > returning an HTML document that contains a magic  tag in
> > the page header
> >
> > https://github.com/ovirt/ovirt-imageio/imageio-go"/>
>
> I found that this does not work, Go tools do not support a module not
> in the root directory of a git repo.

I forgot to include the relevant issue:
https://github.com/golang/go/issues/34055
___
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/H4EAHH7XCARODVS6YF5WMDXN77BQ3QD3/

[ovirt-devel] Re: Publishing oVirt Go modules under ovirt.org namespace

[Nir Soffer]

On Wed, Oct 27, 2021 at 6:18 PM Nir Soffer  wrote:
>
> Currently we have 3 go modules:
>
> - github.com/ovirt/go-ovirt
>   https://github.com/oVirt/go-ovirt/
>   seems that this repo generated by 
> https://github.com/oVirt/ovirt-engine-sdk-go
>
> - github.com/ovirt/go-ovirt-client
>https://github.com/oVirt/go-ovirt-client
>
> - github.com/ovirt/go-ovirt-client-log
>https://github.com/oVirt/go-ovirt-client-log
>
> These modules share the issue of depending on the hosting service
> and the repo the code is located.
>
> I started to work on the imageio go module here:
> https://gerrit.ovirt.org/c/ovirt-imageio/+/117277
>
> And I'm trying to avoid the issues above by naming the module:
>
> ovirt.org/imageio
>
> The module name does not depend on the hosting service, or on the
> actual repo or the location in the repo.
>
> To make this work, the web server at ovirt.org should serve this resource:
>
> https://ovirt.org/imageio
>
> returning an HTML document that contains a magic  tag in
> the page header
>
> https://github.com/ovirt/ovirt-imageio/imageio-go"/>

I found that this does not work, Go tools do not support a module not
in the root directory of a git repo.

We have several options to solve this:
1. Create new git repo for the Go imageio library
2. Publish the library using "github.com/ovirt/ovirt-imageio/imageio-go"
3. Serve the module from our web server (e.g. resources.ovirt.org) using
   the go proxy protocol.

I don't like option 1 since adding more tiny repos makes it harder to work with
the code and test it. We already have too many repos.

I don't like option 2 since this import path is horrible, and I don't want to
tie the project to github.

Option 3 is easy to implement - for every release you create a zip file
with the module, and few metadata files, and upload them to a web
server pointerd by the "go-import" meta tag.

We have the same problem with libnbd Go binding, and option 3 is likely
the right solution for it for similar reasons.

I want to get your input on this.

Nir
___
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/VVZYVLFDYTQX4BLMGV7TSHK5GQYFF3OK/

[ovirt-devel] Re: VDSM build failure: unsupported pickle protocol: 5

[Nir Soffer]

On Thu, Oct 28, 2021 at 2:08 PM Marcin Sobczyk  wrote:
>
> Hi,
>
> On 10/28/21 11:59, Sandro Bonazzola wrote:
> > hi,
> > I'm trying to enable copr builds for vdsm (
> > https://gerrit.ovirt.org/c/vdsm/+/117368
> >  )
> >
> > And it's currently failing to rebuild src.rpm (generated on Fedora 34)
> > for el8 with the following error:
> > (https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-8-x86_64/02912480-vdsm/build.log.gz
> > 
> > )
> >
> > make[2]: Entering directory '/builddir/build/BUILD/vdsm-4.50.0.1/lib/vdsm'
> > Making all in api
> > make[3]: Entering directory 
> > '/builddir/build/BUILD/vdsm-4.50.0.1/lib/vdsm/api'
> >Generate vdsm-api.html
> > chmod u+w .
> > PYTHONPATH=./../../:./../../vdsm \
> >   ./schema_to_html.py vdsm-api ./vdsm-api.html
> > Traceback (most recent call last):
> >File "./schema_to_html.py", line 250, in 
> >  main()
> >File "./schema_to_html.py", line 245, in main
> >  api_schema = vdsmapi.Schema((schema_type,), strict_mode=False)
> >File "/builddir/build/BUILD/vdsm-4.50.0.1/lib/vdsm/api/vdsmapi.py", line 
> > 145, in __init__
> >  loaded_schema = pickle.loads(f.read())
> > ValueError: unsupported pickle protocol: 5
> > make[3]: *** [Makefile:697: vdsm-api.html] Error 1
> > make[3]: Leaving directory 
> > '/builddir/build/BUILD/vdsm-4.50.0.1/lib/vdsm/api'
> > make[2]: *** [Makefile:644: all-recursive] Error 1
> > make[2]: Leaving directory '/builddir/build/BUILD/vdsm-4.50.0.1/lib/vdsm'
> > make[1]: *** [Makefile:466: all-recursive] Error 1
> > make[1]: Leaving directory '/builddir/build/BUILD/vdsm-4.50.0.1/lib'
> > make: *** [Makefile:539: all-recursive] Error 1
> > error: Bad exit status from /var/tmp/rpm-tmp.nDfLzv (%build)
> >
> > Sounds like the make dist process ran on Fedora 34 brings a source file 
> > used at build time on el8 in a cpickle format which is not backward 
> > compatible.
> >
> > Seems to be a bug, the cpickle shouldn't be included in the tar.gz, it 
> > should be generated at build time.
> >
> > Comments?
>
> The pickles were introduced here:
>
> https://gerrit.ovirt.org/c/vdsm/+/94196
>
> AFAIR they were added to the vdsm-api package because previously we were
> generating them in during rpm installation in %post section which caused
> issues with oVirt Node.
>
> I'm not sure how easy will it be to not have them in the srpm/tar.gz but
> have them in the rpm. As a quick workaround I can change the pickle
> protocol version that we use [1] to '4', which should work for both
> Fedora 34 and el8.

Creating the pickle when building srpm is bad. This means you must use
some old (slow) pickle protocol that works on all possible platforms, instead
of the highest (fast) protocol available on the target platform.

We should really create the pickle when building the rpm, which is done
in mock, with the right python version.

If we cannot do this then building the cache on the host during configure time
will be an easy solution. Check if the cache exists in /var/lib/cache/vdsm/...
and regenerate it if needed.

If we don't want to run the schema_to_html tool at this time, we can add
the schema in json format - this can be done when building the srpm.
Converting json to pickle is very fast and does not have any dependencies.

Nir

> Regards, Marcin
>
> [1]
> https://github.com/oVirt/vdsm/blob/1969ab99c371ad498ea8693671cec60e2d0d49c2/lib/vdsm/api/schema_to_pickle.py#L46
>
>
> >
> > --
> >
> > Sandro Bonazzola
> >
> > MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
> >
> > Red Hat EMEA 
> >
> > sbona...@redhat.com 
> >
> > 
> >
> > **
> > *Red Hat respects your work life balance. Therefore there is no need to
> > answer this email out of your office hours.
> > *
> > *
> >
> > *
>
___
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/VKYTWLLGEVDWE5OLYRXGNGTB5JXXCMCJ/

[ovirt-devel] Re: Publishing oVirt Go modules under ovirt.org namespace

[Nir Soffer]

On Wed, Oct 27, 2021 at 10:03 PM Yedidyah Bar David  wrote:
>
> On Wed, Oct 27, 2021 at 6:19 PM Nir Soffer  wrote:
>>
>> Currently we have 3 go modules:
>>
>> - github.com/ovirt/go-ovirt
>>   https://github.com/oVirt/go-ovirt/
>>   seems that this repo generated by 
>> https://github.com/oVirt/ovirt-engine-sdk-go
>>
>> - github.com/ovirt/go-ovirt-client
>>https://github.com/oVirt/go-ovirt-client
>>
>> - github.com/ovirt/go-ovirt-client-log
>>https://github.com/oVirt/go-ovirt-client-log
>>
>> These modules share the issue of depending on the hosting service
>> and the repo the code is located.
>>
>> I started to work on the imageio go module here:
>> https://gerrit.ovirt.org/c/ovirt-imageio/+/117277
>>
>> And I'm trying to avoid the issues above by naming the module:
>>
>> ovirt.org/imageio
>>
>> The module name does not depend on the hosting service, or on the
>> actual repo or the location in the repo.
>>
>> To make this work, the web server at ovirt.org should serve this resource:
>>
>> https://ovirt.org/imageio
>>
>> returning an HTML document that contains a magic  tag in
>> the page header
>>
>> https://github.com/ovirt/ovirt-imageio/imageio-go"/>
>>
>> Is this possible with our current infrastructure?
>
>
> If that's all you want, I guess you should simply open an infra ticket, no?

I want to discuss the issue and possible solutions

>> Should we rename all the go modules to fit this scheme?
>
>
> Perhaps do something slightly different: Use a subdir, or a subdomain,
> such as go.ovirt.org/imageio or ovirt.org/go/imageio, and ask for this
> place to be managed using a git repo somewhere (in gerrit or elsewhere), so
> that when you merge there stuff, something updates the namespace
> automatically. This way you do not need to ping infra per each project.

This is nicer since using "ovirt.org/name" for a go module prevents
using this name for something else.

But hopefully we can do this using the current ovirt site
infrastructure, for example
adding a wiki page with a special metadata key, or syntax that will generate
the  tag like:

   ---
   title: oVirt ... Go module
   meta: name=... content=...
   ---
   Page text...

This way the same page can also contain useful content about the resource.

Nir
___
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/EEZI4USO2OKJKTN6VQO7S7F3GLPJVHGK/

[ovirt-devel] Publishing oVirt Go modules under ovirt.org namespace

[Nir Soffer]

Currently we have 3 go modules:

- github.com/ovirt/go-ovirt
  https://github.com/oVirt/go-ovirt/
  seems that this repo generated by https://github.com/oVirt/ovirt-engine-sdk-go

- github.com/ovirt/go-ovirt-client
   https://github.com/oVirt/go-ovirt-client

- github.com/ovirt/go-ovirt-client-log
   https://github.com/oVirt/go-ovirt-client-log

These modules share the issue of depending on the hosting service
and the repo the code is located.

I started to work on the imageio go module here:
https://gerrit.ovirt.org/c/ovirt-imageio/+/117277

And I'm trying to avoid the issues above by naming the module:

ovirt.org/imageio

The module name does not depend on the hosting service, or on the
actual repo or the location in the repo.

To make this work, the web server at ovirt.org should serve this resource:

https://ovirt.org/imageio

returning an HTML document that contains a magic  tag in
the page header

https://github.com/ovirt/ovirt-imageio/imageio-go"/>

Is this possible with our current infrastructure?

Should we rename all the go modules to fit this scheme?

Nir
___
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/EGNSRV4UTIPOJQBDM5MDEENJMKUBVFUD/

[ovirt-devel] Re: Introduction

[Nir Soffer]

On Tue, Oct 19, 2021 at 10:44 AM Maithreyi Gopal
 wrote:

Welcome Maithreyi!

> On Tue, Oct 19, 2021 at 9:14 AM Yedidyah Bar David  wrote:
...
>>> I am Maithreyi Gopal, from Nuremberg, Germany.  I am looking to start 
>>> contributing to open source  projects and would like to introduce myself to 
>>> you.
>>>
>>> I have a lot of Software Development Experience to offer. I have a few 
>>> years of experience working with infrastructure teams on the Cisco ASR9k 
>>> routers. I have a Masters in Networking and Design
>>> I currently work on developing drivers and communication protocols for 
>>> image transfer at Siemens Healthcare.

If you are interested in image transfer, maybe you would like to check the
ovirt-imageio project?
https://github.com/ovirt/ovirt-imageio

It can be a good opportunity to learn about python, HTTP, NBD, testing,
incremental backup, and storage.

It is not very useful without oVirt (yet), so if you look for something you
can use yourself now, this may not be the best option for you.

The project provides a server and client for transferring disk images
to/from oVirt. This project enables oVirt incremental backup API,
importing VMs to
oVirt (e.g. via virt-v2v) and exporting VMs to other systems (e.g
openshift virtualization).

This is a relatively small code base (14694 lines of python, 193 lines
of C) with very
good test coverage (~90%), and relatively clean code.

The most important task we have at the moment is creating a command line
tool replacing lot of example scripts from the oVirt python SDK:
https://bugzilla.redhat.com/1626262

Another small task that may fit new contributors is supporting standard NBD URL
syntax:
https://bugzilla.redhat.com/1849091

Future ideas that we are thinking about:
- Multithreaded checksums (https://gerrit.ovirt.org/c/ovirt-imageio/+/113379)
- Go client library
- Using libnbd library instead of our own NBD python library
- Packaging the project for more distros (Fedora, Debian, ...)
- Migrating the project to github or gitlab
- Making it useful outside of oVirt

Like most other projects, we always need help with improving documentation
and automated testing.

You can start here:
http://ovirt.github.io/ovirt-imageio/development.html

>>> I want to be able to use my background to start contributing to open source 
>>> and learn new technologies. I come with no prior open source contributions. 
>>> If somebody is willing to point me in the right direction and probably help 
>>> me with an easy first contribution, I would really appreciate it. I am most 
>>> proficient in C and python.
>>
>>
>> Do you use Open Source in your daily work? At home? Elsewhere? Do you use 
>> oVirt?
>>
>> Personally, I think it's best to start contributing to software you actually 
>> use.

This works great for me, in a way; I never contributed to Chrom or vim, which
are the  projects I used most of the time, but I did contribute to projects used
by oVirt, like python, sanlock and qemu.

>> If you are interested in oVirt, you should probably start by looking around 
>> https://www.ovirt.org/develop/ .
>>
>> If in "easy first contribution" you refer to a code change/patch, then I 
>> might warn you that it's not really that "easy", if you have no experience 
>> with oVirt and related technologies as a user, first. I think it took me 
>> around a month, back then...

Contributing to ovirt is certainly not easy, but with some help and by focusing
on specific area it can be.

Nir
___
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/4SC5CVSY6KXF3ANDII2ONA3D7YKRIG2Z/

[ovirt-devel] Re: Nessus Scans

[Nir Soffer]

On Tue, Sep 28, 2021 at 9:59 AM James Loker-Steele via Devel
 wrote:
>
> Hi Folks,
> I have a question from our InfoSec team,
>
> We run a nessus scan each week and some "issues" one of which is a critical
> 1. Python - Unsupported Version Detected: This is on the websocket proxy. Is 
> it possible to use python3 on websocket proxy?

Python 2.7 is fully supported on RHEL 7. The report is wrong, please
file a bug for nessus.

In 4.4. all oVirt projects were ported to Python 3.6.

Nir
___
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/LWVZGZHNUOELH6BRKDSXTP2MSVC4PH7I/

[ovirt-devel] Re: vdsm pylint runs don't report some errors

[Nir Soffer]

On Mon, Sep 13, 2021 at 4:02 PM Harel Braha  wrote:
>
> Hi,
>
> When I ran vdsm linters in my local environment, I received errors such as:
> ` lib/vdsm/storage/lvm.py:1837:14: E1120: No value for argument 'rc' in 
> constructor call (no-value-for-parameter)`
> On inspection of the CI logs from other runs, we found an internal Pylint 
> error[1].
> It appears that this error prevents Pylint from working properly.
> As a result of bumping up pylint version in order to overcome this error,
> we got the same errors as in my local environment [2], and another error that 
> seems to be a false positive:
> `lib/vdsm/storage/volumemetadata.py:101:29: E1102: validate is not callable 
> (not-callable)`
> We don't have a path in the tests that would reach the code part that
> raises the problematic exception[3], but it seems legit.

You can send a patch to use more recent version of pylint.

We pin the version to avoid random failures when pylint changes the rules
so we need to update the pinned version from time to time.

>
> any suggestions?
>
> [1] 
> https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/29546/pipeline/151/#step-264-log-786
>
> [2] 
> https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-patch/detail/vdsm_standard-check-patch/29566/pipeline#step-264-log-854
>
> [3] 
> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/29565/artifact/check-patch.tests-py3.el8stream.x86_64/htmlcov-storage/_home_jenkins_workspace_vdsm_standard-check-patch_vdsm_lib_vdsm_storage_lvm_py.html#t1837
>
> best regards,
> Harel
>
___
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/6PSSLFOF7SQBWVN6QEZLJNKCVFLDREHI/

[ovirt-devel] Re: ovirt-imageio fails tests on CentOS Stream 9 / qemu-6.1.0

[Nir Soffer]

On Wed, Sep 8, 2021 at 5:20 PM Sandro Bonazzola  wrote:
>
> Hi,
> running ovirt-imageio check-patch on CentOS Stream 9 fails.
> Is anyone around from the storage team who can have a look?
> https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/3974//artifact/check-patch.el9stream.x86_64/mock_logs/script/stdout_stderr.log

I checked the failures, the first is a wrong check that should be
removed, the second
is testing for tls 1.1 support that we should really remove at this point.

Nir

> Thanks,
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA
>
> sbona...@redhat.com
>
> Red Hat respects your work life balance. Therefore there is no need to answer 
> this email out of your office hours.
>
>
> ___
> 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/UL5H2CMHFHQIIPE56SC6VCFOQEO45AN5/
___
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/ILPT7ZSMPR2FGHWNH4VGVVTQEXVNRXI6/

[ovirt-devel] Re: Python SDK 4.4.15 problems

[Nir Soffer]

On Mon, Aug 16, 2021 at 12:38 PM francesco--- via Devel  wrote:
> in a new deployed host (Centos8, oVirt 4.4) with python module 
> ovirt-engine-sdk-python 4.4.15 I was unable to use the Python SDK API. The 
> script hanged in the connection test, with the following strace:

Which script?
What was the output of the script?
Most scripts log to example.log, do you have any clue there?
Some scripts support --debug option to log more info to the log. Did you use it?

If you run strace, use:

strace -f -tt -T -o output.strace command ...

And share the complete trace.

This will show all threads/child processes and add timestamps and syscalls
elapsed times.

Nir
___
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/77CYNCUVZ2YJ2FQBLHIWPR632ORAUSM5/

[ovirt-devel] Inconsistent Jenkins node time zones - use UTC?

[Nir Soffer]

We found a broken test that fail when running on EDT timezone:
https://gerrit.ovirt.org/c/vdsm/+/116187

However this test fails randomly. Looking at the run logs, we see that
some nodes
are using UTC:

[2021-08-13T15:04:26.855Z] ## Fri Aug 13 15:04:26 UTC 2021 Running
env: el8stream:centos-stream-8-x86_64

But others use EDT:

[2021-08-13T16:32:26.866Z] ## Fri Aug 13 12:32:26 PM EDT 2021
Running env: el8stream:centos-stream-8-x86_64

Run logs:
- 
https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_standard-check-patch/runs/29231/nodes/152/steps/240/log/?start=0
- 
https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_standard-check-patch/runs/29229/nodes/152/steps/264/log/?start=0

Having different time zones on the same system wastes time for everyone.

Please use the same timezone on all systems. I think using UTC will
make everyone
life easier since developers and admins are located on multiple
timezones and everyone
know what is UTC.

Nir
___
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/YOGKZJAUJ55JFZIXRLUFMBCR7TUNUNSC/

[ovirt-devel] Re: [VDSM] CI fails in QemuGuestAgentTests.test_pci_devices

[Nir Soffer]

On Thu, Aug 12, 2021 at 7:00 PM Milan Zamazal  wrote:
>
> Milan Zamazal  writes:
>
> > Milan Zamazal  writes:
> >
> >> Nir Soffer  writes:
> >>
> >>> VDSM CI is failing now consistently. Last related change is:
> >>> https://gerrit.ovirt.org/c/vdsm/+/116090
> >>
> >> It doesn't look related.
> >>
> >>> Build:
> >>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/29212//artifact/check-patch.tests-py3.el8stream.x86_64/mock_logs/script/stdout_stderr.log
> >>>
> >>> _ QemuGuestAgentTests.test_pci_devices 
> >>> _
> >>>
> >>> self =  >>> testMethod=test_pci_devices>
> >>>
> >>> def test_pci_devices(self):
> >>> devices = 
> >>> self.qga_poller._qga_call_get_devices(self.vm)['pci_devices']
> >>> # Ethernet is returned twice by the agent but should appear only
> >>> # once in the list
> >>> assert len(devices) == 2
> >>> eth = [d for d in devices if d['device_id'] == 4096][0]
> >>> assert eth == {
> >>> 'device_id': 4096,
> >>> 'driver_date': '2019-08-12',
> >>> 'driver_name': 'Red Hat VirtIO Ethernet Adapter',
> >>> 'driver_version': '100.80.104.17300',
> >>> 'vendor_id': 6900,
> >>> }
> >>> balloon = [d for d in devices if d['device_id'] == 4098][0]
> >>>>   assert balloon == {
> >>> 'device_id': 4098,
> >>> 'driver_date': '2019-08-12',
> >>> 'driver_name': 'VirtIO Balloon Driver',
> >>> 'driver_version': '100.80.104.17300',
> >>> 'vendor_id': 6900,
> >>> }
> >>> E   AssertionError: assert {'device_id':...4.17300', ...} ==
> >>> {'device_id':...4.17300', ...}
> >>> E Omitting 4 identical items, use -vv to show
> >>> E Differing items:
> >>> E {'driver_date': '2019-08-11'} != {'driver_date': '2019-08-12'}
> >>>
> >>> Are we using real time in this test?
> >>
> >> No, I think the problem is related to the following line
> >>
> >>   'driver-date': 1565568,
> >>
> >> in qemuguestagent_test.py and the corresponding conversion
> >>
> >>   date = datetime.date.fromtimestamp(date // 1e9).isoformat()
> >>
> >> in guestagenthelpers.py.
> >>
> >> The test passes on my computer so I wonder whether it may be a bug in
> >> some version of python3-dateutil.  I also wonder whether the fact that
> >> it occurred on 12 August is just a coincidence.
> >
> > Looks correct also on current CentOS Stream 8:
> >
> >   >>> datetime.datetime.fromtimestamp(1565568 // 
> > 1e9).isoformat()
> >   '2019-08-12T00:00:00'
> >
> > And there was no leap second this year that could cause it.
> >
> > I guess it could be fixed by shifting the driver timestamp a bit forward
> > but then the test wouldn't check for these kinds of errors anymore.  So
> > I'd suggest disabling the test if it causes trouble until the failing
> > part is identified.
>
> Or could it be an issue, under some circumstances, with using float in
> the computation (which is wrong anyway)?  Let's try:
> https://gerrit.ovirt.org/c/vdsm/+/116182

Creating datetime from timestamp means we use real time instead of
monotonic time which is suspected.

I hope we don't use real time in the actual code and this is only a test issue.

We have other issues now:

- consistent timeout in merge tests

[2021-08-12T15:54:08.218Z] storage/merge_test.py .x..x..
=
[2021-08-12T15:54:08.218Z] = Watched process timed out
=
[2021-08-12T15:54:08.218Z]
=
[2021-08-12T15:54:08.218Z] [New LWP 31618]
[2021-08-12T15:54:08.218Z] [Thread debugging using libthread_db enabled]
[2021-08-12T15:54:08.218Z] Using host libthread_db library
"/lib64/libthread_db.so.1".
[2021-08-12T15:54:08.218Z] 0x7f0bcb0a4a41 in poll () from /lib64/libc.so.6
[2021-08-12T15:54:08.218Z]
[2021-08-12T15:54:08.218Z] Thread 2 (Thread 0x7f0bb1e35700 (LWP 31618)):
[2021-08-12T15:54:08.218Z] Undefined command: "py-bt".  Try "help".
[2021-08-12T15:54:08.218Z] [Inferior 1 (process 22705) detached]

I'm trying to debug it here:
https://gerrit.ovirt.org/c/vdsm/+/116180

- network tests failing:

[2021-08-12T15:56:17.928Z] network/integration/link_bond_test.py
...F...FF.FF.  [ 11%]

Maybe changes in centos stream are breaking us again.

Nir
___
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/2NK3USQOTFT6QGED4Q4QUY2GM2EFDDQM/

[ovirt-devel] [VDSM] CI fails in QemuGuestAgentTests.test_pci_devices

[Nir Soffer]

VDSM CI is failing now consistently. Last related change is:
https://gerrit.ovirt.org/c/vdsm/+/116090

Build:
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/29212//artifact/check-patch.tests-py3.el8stream.x86_64/mock_logs/script/stdout_stderr.log

_ QemuGuestAgentTests.test_pci_devices _

self = 

def test_pci_devices(self):
devices = self.qga_poller._qga_call_get_devices(self.vm)['pci_devices']
# Ethernet is returned twice by the agent but should appear only
# once in the list
assert len(devices) == 2
eth = [d for d in devices if d['device_id'] == 4096][0]
assert eth == {
'device_id': 4096,
'driver_date': '2019-08-12',
'driver_name': 'Red Hat VirtIO Ethernet Adapter',
'driver_version': '100.80.104.17300',
'vendor_id': 6900,
}
balloon = [d for d in devices if d['device_id'] == 4098][0]
>   assert balloon == {
'device_id': 4098,
'driver_date': '2019-08-12',
'driver_name': 'VirtIO Balloon Driver',
'driver_version': '100.80.104.17300',
'vendor_id': 6900,
}
E   AssertionError: assert {'device_id':...4.17300', ...} ==
{'device_id':...4.17300', ...}
E Omitting 4 identical items, use -vv to show
E Differing items:
E {'driver_date': '2019-08-11'} != {'driver_date': '2019-08-12'}

Are we using real time in this test?

E Use -v to get the full diff
___
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/Y2QMOHQYV5RT7CJ5GRAXEMHHDXRNDKZQ/

[ovirt-devel] Re: Vdsm 4.4.8 branch?

[Nir Soffer]

On Thu, Aug 12, 2021 at 1:58 PM Milan Zamazal  wrote:
>
> Hi,
>
> we are after code freeze for 4.4.8 now.  Can we create a 4.4.8 branch in
> Vdsm now and start 4.4.9 development on master or does anybody need to
> postpone the branch?

From my side there are no pending patches for 4.4.8, and being able to merge new
code for 4.4.9 is good.
___
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/7X6YTOY5BI4UFG3CYSVC6RP7PFUZ4MVU/

[ovirt-devel] Re: ovirt-engine-sdk repository changes

[Nir Soffer]

On Mon, Aug 9, 2021 at 4:05 PM Martin Necas  wrote:
> just bit summary of few changes in ovirt-engine-sdk repo [1]. There was the 
> decision to split the SDK generator and the python SDK itself. So we created 
> a new repository on GitHub called python-ovirt-engine-sdk4 [2].
>
> We switched from Travis CI to GitHub Actions, because Travis no longer 
> supported .org domain where we had our tests. The GitHub Actions 
> automatically builds the SDK and pushes it to the new repo similar to the Go 
> SDK.
>
> There were some issues with the documentation generator [3] so we switched to 
> the new version of pdoc [4].
>
> We migrated the SDK examples because the examples have nothing to do with the 
> generator itself moved it to the new repository [6].

The examples and the generator are different parts of the python sdk. Why
do we need to add another repository? We already have too many repositories.

With this change we lose all the history from the sdk examples, and we
break all the links to the example scripts. Try this search:
https://www.google.co.il/search?q=upload_disk.py

Why was this not discussed here before the change?

Nir
___
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/AYDA3XK6OJWN6S4MERGEUZLDOL3HDMR2/

[ovirt-devel] Re: Migration without shared storage is unsafe (was: Change in ovirt-system-tests[master]: HE: Use node image)

[Nir Soffer]

On Mon, Aug 9, 2021 at 4:01 PM Nir Soffer  wrote:
>
> On Mon, Aug 9, 2021 at 2:42 PM Yedidyah Bar David  wrote:
> >
> > On Mon, Aug 9, 2021 at 1:43 PM Nir Soffer  wrote:
> > >
> > > On Mon, Aug 9, 2021 at 10:35 AM Yedidyah Bar David  
> > > wrote:
> > > >
> > > > On Sun, Aug 8, 2021 at 5:42 PM Code Review  wrote:
> > > > >
> > > > > From Jenkins CI :
> > > > >
> > > > > Jenkins CI has posted comments on this change. ( 
> > > > > https://gerrit.ovirt.org/c/ovirt-system-tests/+/115392 )
> > > > >
> > > > > Change subject: HE: Use node image
> > > > > ..
> > > > >
> > > > >
> > > > > Patch Set 13: Continuous-Integration-1
> > > > >
> > > > > Build Failed
> > > >
> > > > While trying to deactivate a host, the engine wanted to migrate a VM
> > > > (vm0) from host-0 to host-1. vdsm log of host-0 says:
> > > >
> > > > 2021-08-08 14:31:10,076+ ERROR (migsrc/cde311f9) [virt.vm]
> > > > (vmId='cde311f9-9a33-4eb9-8338-fa22ff49edc2') Failed to migrate
> > > > (migration:503)
> > > > Traceback (most recent call last):
> > > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > > 477, in _regular_run
> > > > time.time(), machineParams
> > > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > > 578, in _startUnderlyingMigration
> > > > self._perform_with_conv_schedule(duri, muri)
> > > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > > 667, in _perform_with_conv_schedule
> > > > self._perform_migration(duri, muri)
> > > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > > 596, in _perform_migration
> > > > self._migration_flags)
> > > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line
> > > > 159, in call
> > > > return getattr(self._vm._dom, name)(*a, **kw)
> > > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line 
> > > > 101, in f
> > > > ret = attr(*args, **kwargs)
> > > >   File 
> > > > "/usr/lib/python3.6/site-packages/vdsm/common/libvirtconnection.py",
> > > > line 131, in wrapper
> > > > ret = f(*args, **kwargs)
> > > >   File "/usr/lib/python3.6/site-packages/vdsm/common/function.py",
> > > > line 94, in wrapper
> > > > return func(inst, *args, **kwargs)
> > > >   File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2126, in
> > > > migrateToURI3
> > > > raise libvirtError('virDomainMigrateToURI3() failed')
> > > > libvirt.libvirtError: Unsafe migration: Migration without shared
> > > > storage is unsafe
> > >
> > > Please share the vm xml:
> > >
> > > sudo virsh -r dumpxl vm-name
> >
> > I think you should be able to find a dump of it in vdsm.log:
> >
> > https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/18650/artifact/check-patch.he-basic_suite_master.el8.x86_64/test_logs/ost-he-basic-suite-master-host-0/var/log/vdsm/vdsm.log
> >
> > I think the first line of starting a migration is:
> >
> > 2021-08-08 14:31:08,350+ DEBUG (jsonrpc/4) [jsonrpc.JsonRpcServer]
> > Calling 'VM.migrate' in bridge with {'vmID':
> > 'cde311f9-9a33-4eb9-8338-fa22ff49edc2', 'params':
> >
> > A few lines later:
> >
> > 2021-08-08 14:31:08,387+ DEBUG (migsrc/cde311f9)
> > [virt.metadata.Descriptor] dumped metadata for
> > cde311f9-9a33-4eb9-8338-fa22ff49edc2:  > encoding='utf-8'?>
> > 
> > 98304
>
> This is not the vm xml but the metadata xml.
>
> Looking at the logs on both hosts:
>
> [nsoffer@sparse ost]$ head -1 *vdsm.log
> ==> host0-vdsm.log <==
> 2021-08-08 13:16:04,676+ INFO  (MainThread) [vds] (PID: 65169) I
> am the actual vdsm 4.40.80.3.12.git6d67b935b
> ost-he-basic-suite-master-host-0 (4.18.0-326.el8.x86_64) (vdsmd:162)
>
> ==> host1-vdsm.log <==
> 2021-08-08 15:40:54,367+0200 INFO  (MainThread) [vds] (PID: 23005) I
> am the actual vdsm 4.40.80.4.5.git4309a3949
> ost-he-basic-suite-master-host-1 (4.18.0-326.el8.x86_64) (vd

[ovirt-devel] Re: Migration without shared storage is unsafe (was: Change in ovirt-system-tests[master]: HE: Use node image)

[Nir Soffer]

On Mon, Aug 9, 2021 at 2:42 PM Yedidyah Bar David  wrote:
>
> On Mon, Aug 9, 2021 at 1:43 PM Nir Soffer  wrote:
> >
> > On Mon, Aug 9, 2021 at 10:35 AM Yedidyah Bar David  wrote:
> > >
> > > On Sun, Aug 8, 2021 at 5:42 PM Code Review  wrote:
> > > >
> > > > From Jenkins CI :
> > > >
> > > > Jenkins CI has posted comments on this change. ( 
> > > > https://gerrit.ovirt.org/c/ovirt-system-tests/+/115392 )
> > > >
> > > > Change subject: HE: Use node image
> > > > ..
> > > >
> > > >
> > > > Patch Set 13: Continuous-Integration-1
> > > >
> > > > Build Failed
> > >
> > > While trying to deactivate a host, the engine wanted to migrate a VM
> > > (vm0) from host-0 to host-1. vdsm log of host-0 says:
> > >
> > > 2021-08-08 14:31:10,076+ ERROR (migsrc/cde311f9) [virt.vm]
> > > (vmId='cde311f9-9a33-4eb9-8338-fa22ff49edc2') Failed to migrate
> > > (migration:503)
> > > Traceback (most recent call last):
> > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > 477, in _regular_run
> > > time.time(), machineParams
> > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > 578, in _startUnderlyingMigration
> > > self._perform_with_conv_schedule(duri, muri)
> > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > 667, in _perform_with_conv_schedule
> > > self._perform_migration(duri, muri)
> > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> > > 596, in _perform_migration
> > > self._migration_flags)
> > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line
> > > 159, in call
> > > return getattr(self._vm._dom, name)(*a, **kw)
> > >   File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line 
> > > 101, in f
> > > ret = attr(*args, **kwargs)
> > >   File 
> > > "/usr/lib/python3.6/site-packages/vdsm/common/libvirtconnection.py",
> > > line 131, in wrapper
> > > ret = f(*args, **kwargs)
> > >   File "/usr/lib/python3.6/site-packages/vdsm/common/function.py",
> > > line 94, in wrapper
> > > return func(inst, *args, **kwargs)
> > >   File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2126, in
> > > migrateToURI3
> > > raise libvirtError('virDomainMigrateToURI3() failed')
> > > libvirt.libvirtError: Unsafe migration: Migration without shared
> > > storage is unsafe
> >
> > Please share the vm xml:
> >
> > sudo virsh -r dumpxl vm-name
>
> I think you should be able to find a dump of it in vdsm.log:
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/18650/artifact/check-patch.he-basic_suite_master.el8.x86_64/test_logs/ost-he-basic-suite-master-host-0/var/log/vdsm/vdsm.log
>
> I think the first line of starting a migration is:
>
> 2021-08-08 14:31:08,350+ DEBUG (jsonrpc/4) [jsonrpc.JsonRpcServer]
> Calling 'VM.migrate' in bridge with {'vmID':
> 'cde311f9-9a33-4eb9-8338-fa22ff49edc2', 'params':
>
> A few lines later:
>
> 2021-08-08 14:31:08,387+ DEBUG (migsrc/cde311f9)
> [virt.metadata.Descriptor] dumped metadata for
> cde311f9-9a33-4eb9-8338-fa22ff49edc2:  encoding='utf-8'?>
> 
> 98304

This is not the vm xml but the metadata xml.

Looking at the logs on both hosts:

[nsoffer@sparse ost]$ head -1 *vdsm.log
==> host0-vdsm.log <==
2021-08-08 13:16:04,676+ INFO  (MainThread) [vds] (PID: 65169) I
am the actual vdsm 4.40.80.3.12.git6d67b935b
ost-he-basic-suite-master-host-0 (4.18.0-326.el8.x86_64) (vdsmd:162)

==> host1-vdsm.log <==
2021-08-08 15:40:54,367+0200 INFO  (MainThread) [vds] (PID: 23005) I
am the actual vdsm 4.40.80.4.5.git4309a3949
ost-he-basic-suite-master-host-1 (4.18.0-326.el8.x86_64) (vdsmd:162)

- The hosts clocks are using different time zones (+ vs +0200) is
this intended?
- You are testing different versions of vdsm - is this intended?

We have about 60 errors:
$ grep 'Migration without shared storage is unsafe' host0-vdsm.log | wc -l
60

Looking at the first migration that failed, the vm xml is here:

2021-08-08 14:20:34,127+ INFO  (vm/cde311f9) [virt.vm]
(vmId='cde311f9-9a33-4eb9-8338-fa22ff49edc2') 
http://libvirt.org/schemas/domain/qemu/1.0;
xmlns:ovirt-vm="http://ovirt.org/vm/1.0; type="kv

[ovirt-devel] Re: Migration without shared storage is unsafe (was: Change in ovirt-system-tests[master]: HE: Use node image)

[Nir Soffer]

On Mon, Aug 9, 2021 at 10:35 AM Yedidyah Bar David  wrote:
>
> On Sun, Aug 8, 2021 at 5:42 PM Code Review  wrote:
> >
> > From Jenkins CI :
> >
> > Jenkins CI has posted comments on this change. ( 
> > https://gerrit.ovirt.org/c/ovirt-system-tests/+/115392 )
> >
> > Change subject: HE: Use node image
> > ..
> >
> >
> > Patch Set 13: Continuous-Integration-1
> >
> > Build Failed
>
> While trying to deactivate a host, the engine wanted to migrate a VM
> (vm0) from host-0 to host-1. vdsm log of host-0 says:
>
> 2021-08-08 14:31:10,076+ ERROR (migsrc/cde311f9) [virt.vm]
> (vmId='cde311f9-9a33-4eb9-8338-fa22ff49edc2') Failed to migrate
> (migration:503)
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> 477, in _regular_run
> time.time(), machineParams
>   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> 578, in _startUnderlyingMigration
> self._perform_with_conv_schedule(duri, muri)
>   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> 667, in _perform_with_conv_schedule
> self._perform_migration(duri, muri)
>   File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line
> 596, in _perform_migration
> self._migration_flags)
>   File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line
> 159, in call
> return getattr(self._vm._dom, name)(*a, **kw)
>   File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line 101, 
> in f
> ret = attr(*args, **kwargs)
>   File "/usr/lib/python3.6/site-packages/vdsm/common/libvirtconnection.py",
> line 131, in wrapper
> ret = f(*args, **kwargs)
>   File "/usr/lib/python3.6/site-packages/vdsm/common/function.py",
> line 94, in wrapper
> return func(inst, *args, **kwargs)
>   File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2126, in
> migrateToURI3
> raise libvirtError('virDomainMigrateToURI3() failed')
> libvirt.libvirtError: Unsafe migration: Migration without shared
> storage is unsafe

Please share the vm xml:

sudo virsh -r dumpxl vm-name

Nir
___
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/PWYKPD4AJ7GD6QNA5XOLVJC6CMOYEHDW/

[ovirt-devel] Re: OST HE: Engine VM went down due to cpu load (was: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 2126 - Failure!)

[Nir Soffer]

On Sun, Aug 8, 2021 at 10:14 AM Yedidyah Bar David  wrote:
>
> On Thu, Aug 5, 2021 at 9:31 AM Yedidyah Bar David  wrote:
> >
> > On Wed, Aug 4, 2021 at 1:56 PM Michal Skrivanek
> >  wrote:
> > > I don’t really know for sure, but AFAICT it should be real data from the 
> > > start.
> > > Maybe for the first interval, but afterwards it’s always a libvirt 
> > > reported value
> >
> > Adding Nir. Not sure who else... sorry.
> >
> > This now happened again:
> >
> > https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2129/
> >
> > Console has:
> >
> > 06:25:25 2021-08-05 03:25:25+,873 INFO[root] Starting the
> > engine VM... (test_008_restart_he_vm:96)
> >
> > broker.log has (I think it only logs once a minute):
> >
> > Thread-4::INFO::2021-08-05
> > 05:25:31,995::cpu_load_no_engine::126::cpu_load_no_engine.CpuLoadNoEngine::(calculate_load)
> > System load total=0.8164, engine=0., non-engine=0.8164
> > Thread-4::INFO::2021-08-05
> > 05:26:32,072::cpu_load_no_engine::126::cpu_load_no_engine.CpuLoadNoEngine::(calculate_load)
> > System load total=0.8480, engine=0., non-engine=0.8480
> > Thread-4::INFO::2021-08-05
> > 05:27:32,175::cpu_load_no_engine::126::cpu_load_no_engine.CpuLoadNoEngine::(calculate_load)
> > System load total=0.7572, engine=0.2656, non-engine=0.4916
> >
> > vdsm.log [1] has:
> >
> > 2021-08-05 05:25:29,017+0200 DEBUG (jsonrpc/4) [jsonrpc.JsonRpcServer]
> > Calling 'VM.create' in bridge...
> >
> > 2021-08-05 05:25:31,991+0200 DEBUG (jsonrpc/7) [api] FINISH getStats
> > response={'status': {'code': 0, 'message': 'Done'}, 'statsList':
> > [{'statusTime': '2152587436', 'status': 'WaitForLaunch', 'vmId':
> > '230ea8e8-e365-46cd-98fa-e9d6a653306f', 'vmName': 'HostedEngine',
> > 'vmType': 'kvm', 'kvmEnable': 'true', 'acpiEnable': 'true',
> > 'elapsedTime': '2', 'monitorResponse': '0', 'clientIp': '',
> > 'timeOffset': '0', 'cpuUser': '0.00', 'cpuSys': '0.00',...
> >
> > and 17 more such [2] lines. Line 11 is the first one with cpuUser !=
> > 0.00, at '2021-08-05 05:27:02', 92 seconds later. Incidentally (or
> > not), this is also the first line with 'network' in it. There are
> > other differences along the way - e.g. I see status moving from
> > WaitForLaunch to 'Powering up' and to 'Up', but the first 'Up' line is
> > number 7 - 40 seconds before cpuUser>0.

Milan should be able to help with this.

In storage monitoring we avoid this issue by reporting actual=False
before we got the first monitoring results, so engine can wait for the actual
results.
https://github.com/oVirt/vdsm/blob/4309a39492040300e1b983eb583e8847f5cc7538/lib/vdsm/storage/monitor.py#L297

> > I'd like to clarify that I do not see this mainly as an OST issue, but
> > more as a general HE HA issue - if users start global maint, then
> > restart the engine vm, then exit global maint too quickly, the
> > reported high cpu load might make the machine go down. In OST, I can
> > easily just add another 60 seconds or so delay after the engine is up.
> > Of course we can do the same also in HA, and I'd be for doing this, if
> > we do not get any more information (or find out that this is a
> > recently-introduced bug and fix it).

If this is a real issue you should be able to reproduce this on a real system.

Nir
___
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/UZPQE6TUC433FRNMXO6LENYDNRJ7EE5L/

[ovirt-devel] Re: RHV and oVirt CBT issue

[Nir Soffer]

On Fri, Jul 30, 2021 at 5:47 AM luwen.zhang  wrote:
> Sorry I was trying to open a new thread for this issue, but it seems I failed 
> to submit. Here let me explain how the issue is reproduced.
>
> It’s a regular backup by using CBT+imageip API, after a series of successful 
> backup, at one of the backup session beginning, when we try to obtain the VM 
> config and the snapshot list (obtain snapshot list can determine the VM 
> virtual disk format is RAW or QCOW2)

Why do you need the snapshot list when doing incremental backup? What you need
is the list of disks in the vms, accessible via:

GET /vms/{vm-id}/diskattachments

For each disk attachment, get the disk using the diskattachment.disk.id:

GET /disks/{disk-id}/

Please check how we do this in backup_vm.py example:
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/backup_vm.py#L445

> by using `GET vms//snapshots`, but get the following error.
>
> 
>
> 
>
> duplicate key acf1edaa-e950-4c4f-94df-1bd6b3da49c1 (attempted 
> merging values 
> org.ovirt.engine.core.common.businessentities.storage.diskimage@5103046c and 
> org.ovirt.engine.core.common.businessentities.storage.diskimage@d973046c)
>
> Operation Failed
>
> 

We need a much more detailed steps.

This is a typical backup flow:

1. Start incremental backup

2. Wait until backup is ready (phase == READY)

3. Start image transfer for incremental backup

4. Wait until image transfer is ready (phase == TRANSFERRING)

5. Download disk incremental data

6. Finalize transfer

7. Wait until transfer is finished (phase == FINISHED_SUCCESS/FINISHED_FAILURE)

This is not easy, see this example:

https://github.com/oVirt/ovirt-engine-sdk/blob/ac6f05bb5dcd8fdee2a67b2a296ade377661836a/sdk/examples/helpers/imagetransfer.py#L269

8. Finalize backup

9. Wait until backup is finished (phase == FINISHED/FAILED)

This is easier, but possible only since 4.4.7:

https://github.com/oVirt/ovirt-engine-sdk/blob/ac6f05bb5dcd8fdee2a67b2a296ade377661836a/sdk/examples/backup_vm.py#L341

10. Rebase backup image on previous backup (if you store backup as qcow2 layers)

Where in this flow you get the snapshot list (and other stuff?)

Getting snapshots list is likely not needed for backup, but we need to fix it
in case it is broken while running backups or image transfers.

Do you run this flow in a loop? Maybe you do not wait until the previous image
transfer was finished before starting a new backup?

> After this, on oVirt engine web console, the VM show 2 disks (actually it 
> only has 1) , and the disk status always showing “Finalizing”, it’s been more 
> than 30 hours now, and during this, cannot modify VM disk or take snapshots.
>
> Before upgrading oVirt engine to 4.4.7.7-1.el8 this problem happened 
> frequently, after upgrading, the frequency is reduced.
>
> Here I’m adding the engine logs and vdsm logs.
> Engine logs: 
> https://drive.google.com/file/d/1T3-EOxYYl3oFZOA9VMMBte5WyBoUO48U/view?usp=sharing
> VDSM logs: 
> https://drive.google.com/file/d/1x0B8lGqnKEDrgn666CuN3hqUGwD7fcYv/view?usp=sharing

Thanks, we will check the logs next week.

> Thanks & regards!
> On 07/29/2021 19:20，Nir Soffer wrote：
>
> On Thu, Jul 29, 2021 at 10:08 AM luwen.zhang  wrote:
>
> The problem occurred yesterday, but we waited for more than 20 hours, still 2 
> disks and in Finalizing state.
>
>
> If the image transfer is "finalizing" it means the image transfer is
> trying to finalize, but the operation could not complete.
>
> In this phase the disk remains locked, and it should not be possible
> to start a new image transfer
> (e.g perform another backup).
>
> Engine and vdsm logs should explain why the image transfer is stuck in
> the finalizing phase.
>
> Can you add detailed instructions on how to reproduce this issue?
>
___
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/T4JXFOILOB6CLNJIXHTV3Y2J6RY4VAFA/

[ovirt-devel] Re: RHV and oVirt CBT issue

[Nir Soffer]

On Thu, Jul 29, 2021 at 10:08 AM luwen.zhang  wrote:
> The problem occurred yesterday, but we waited for more than 20 hours, still 2 
> disks and in Finalizing state.

If the image transfer is "finalizing" it means the image transfer is
trying to finalize, but the operation could not complete.

In this phase the disk remains locked, and it should not be possible
to start a new image transfer
(e.g perform another backup).

Engine and vdsm logs should explain why the image transfer is stuck in
the finalizing phase.

Can you add detailed instructions on how to reproduce this issue?
___
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/EEAWT3MSDAHASPYKFFW6X6SKXWFELY7L/

[ovirt-devel] Re: RHV and oVirt CBT issue

[Nir Soffer]

On Tue, Jul 27, 2021 at 9:47 AM luwen.zhang  wrote:

>
> Dear team could you please help on the below issue?
>
> Thanks Sandro for the advice!
> On 07/27/2021 14:22，Sandro Bonazzola
>  wrote：
>
> I would recommend to ask this on devel@ovirt.org.
> Looping in +Eyal Shenitzky 
>
> Il giorno mar 27 lug 2021 alle ore 08:14 luwen.zhang <
> luwen.zh...@vinchin.com> ha scritto:
>
>>
>> Dear team,
>>
>> We had implemented CBT support for RHV and oVirt in our new version, but
>> when testing we encountered problems of obtain VM increments and also had
>> abnormal with the VM virtual disks.
>>
>> Our testing environment as below:
>> OS Version: RHEL - 8.4.2105.0 - 3.el8
>> OS Description: oVirt Node 4.4.7
>> Kernel Version: 4.18.0 - 315.el8.x86_64
>> KVM Version: 6.0.0 - 19.el8s
>> LIBVIRT Version: libvirt-7.4.0-1.el8s
>> VDSM Version: vdsm-4.40.70.6-1.el8
>>
>> One of the problem is after a successful backup, the VM which gets only
>> one virtual disk will get 2 identical virtual disks marked as Complete on
>> oVirt engine web console, like shown below.
>>
>> The additional disk might disappear after a while, but before it’s gone
>> there could be a lot of problems with the VM.
>>
>> 1. We cannot perform a new backup, the backup will fail directly.
>>
>> 2. The VM itself will run into exception, we cannot even power it off,
>> and it will also probably get crashed.
>>
>> 3. If the VM was initially powered off, after backing up, we cannot power
>> on the VM.
>>
>> And there could be some other problems related with this, is this normal
>> or there’s something we did wrong?
>>
>> Thank you in advance for your help!
>>
>
Unfortunately you are hitting this bug:
https://bugzilla.redhat.com/1980428

The bug is fixed in 4.4.7 async release, which should be available now
according to the bug.

Please upgrade to the latest 4.4.7 version.

Nir
___
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/NCYMDMWLI3QQISZZJDJTIAXOJZOYHJSX/

[ovirt-devel] Re: OST failure, bad comment

[Nir Soffer]

On Sat, Jul 10, 2021 at 12:59 AM Nir Soffer  wrote:
>
> OST failed, and posted unprocessed comment:
>
> OST Verified -1
> Patch Set 1: Verified-1
> https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger2/313 :
> OST https://redir.apps.ovirt.org/dj/job/ds-ost-baremetal_manual/$OST_NUMBER
> failed with: $OST_MESSAGE
>
> https://gerrit.ovirt.org/c/vdsm/+/115642#message-b2993761_adbc1b6a
>
> Looking at:
> https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger2/313
>
> It looks like environment issue:
>
> ERROR: Build step failed with exception
>
> java.lang.NullPointerException: no workspace from node
> hudson.slaves.DumbSlave[hpe-bl280g6-12...] which is computer
> hudson.slaves.SlaveComputer@2e2cb321 and has channel null
>
> So we have 2 issues:
> 1. If build fails, error is not handled properly producing bad comment
> 2. the actual build failure

I started another build manually (8543) and it started normally, so this was
probably a temporary issue.

>
> The first issue should be handled by posting a better comment:
>
> OST build error:
> https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger2/313
>
> And OST should not mark the patch as verified -1, since it did not run any 
> test.
>
> Marking a patch as -1 means some tests have failed,  and the author
> needs to check
> why. A build error means OST or CI maintainers need to check why the
> error happened.
___
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/H4Q2MT7R7DXKWHRZK7RGPSOLRYZMVZOP/

[ovirt-devel] OST failure, bad comment

[Nir Soffer]

OST failed, and posted unprocessed comment:

OST Verified -1
Patch Set 1: Verified-1
https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger2/313 :
OST https://redir.apps.ovirt.org/dj/job/ds-ost-baremetal_manual/$OST_NUMBER
failed with: $OST_MESSAGE

https://gerrit.ovirt.org/c/vdsm/+/115642#message-b2993761_adbc1b6a

Looking at:
https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger2/313

It looks like environment issue:

ERROR: Build step failed with exception

java.lang.NullPointerException: no workspace from node
hudson.slaves.DumbSlave[hpe-bl280g6-12...] which is computer
hudson.slaves.SlaveComputer@2e2cb321 and has channel null

So we have 2 issues:
1. If build fails, error is not handled properly producing bad comment
2. the actual build failure

The first issue should be handled by posting a better comment:

OST build error:
https://redir.apps.ovirt.org/dj/job/ds-ost-gating-trigger2/313

And OST should not mark the patch as verified -1, since it did not run any test.

Marking a patch as -1 means some tests have failed,  and the author
needs to check
why. A build error means OST or CI maintainers need to check why the
error happened.
___
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/GBXAV5I2RSVCCZS24ZJQB2NPNWYU7ZCI/

[ovirt-devel] Re: test_cold_incremental_backup_vm2: "Cannot backup VM. The VM is during a backup operation"

[Nir Soffer]

On Wed, Jul 7, 2021 at 11:18 PM Yedidyah Bar David  wrote:
>
> On Sun, Jul 4, 2021 at 8:26 AM  wrote:
> >
> > Project: 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/
> > Build: 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/1291/
> > Build Number: 1291
> > Build Status:  Failure
> > Triggered By: Started by timer
> >
> > -
> > Changes Since Last Success:
> > -
> > Changes for Build #1291
> > [Marcin Sobczyk] network: Add missing 'ansible_hosts' fixture
> >
> >
> >
> >
> > -
> > Failed Tests:
> > -
> > 1 tests failed.
> > FAILED:  
> > basic-suite-master.test-scenarios.test_004_basic_sanity.test_cold_incremental_backup_vm2
> >
> > Error Message:
> > ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is 
> > "[Cannot backup VM. The VM is during a backup operation.]". HTTP response 
> > code is 409.

This is probably caused by changes in backup API in 4.4.7.
The test is likely using the old API, which leads to timeout when
waiting for the backup.

In general, this test not implemented properly. It should use
backup_vm.py script
from the SDK, that was already updated to use the new API. Duplicating
the backup
code in OST means we need duplicate effort in maintaining the tests, and wasting
tons on time on testing the changes in OST.

The test should be skipped until someone can rewrite it properly.

> Something similar now happened to me too:
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17729/
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17729/testReport/junit/basic-suite-master.test-scenarios/test_004_basic_sanity/Invoking_jobs___check_patch_basic_suite_master_el8_x86_64___test_cold_incremental_backup_vm2/
>
> This job triggered also he-basic, which passed. basic failed as in here.
>
> Any idea?
>
> Best regards,
>
> >
> > Stack Trace:
> > engine_api = 
> > get_vm_service_for_vm =  > get_vm_service_for_vm..service_for at 0x7f1f944e1268>
> >
> > @order_by(_TEST_LIST)
> > def test_cold_incremental_backup_vm2(engine_api, get_vm_service_for_vm):
> > _verify_vm_state(engine_api.system_service(), VM2_NAME, 
> > types.VmStatus.DOWN)
> > vm2_backups_service = 
> > get_vm_service_for_vm(VM2_NAME).backups_service()
> > backup.perform_incremental_vm_backup(
> > >   engine_api, vm2_backups_service, DISK2_NAME, "cold_vm_backup")
> >
> > basic-suite-master/test-scenarios/test_004_basic_sanity.py:1056:
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _
> > ost_utils/ost_utils/storage_utils/backup.py:75: in 
> > perform_incremental_vm_backup
> > correlation_id="incremental_" + correlation_id)
> > ost_utils/ost_utils/storage_utils/backup.py:34: in perform_vm_backup
> > ), query={'correlation_id': correlation_id}
> > /usr/lib64/python3.6/site-packages/ovirtsdk4/services.py:34139: in add
> > return self._internal_add(backup, headers, query, wait)
> > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:232: in 
> > _internal_add
> > return future.wait() if wait else future
> > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:55: in wait
> > return self._code(response)
> > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:229: in callback
> > self._check_fault(response)
> > /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:132: in _check_fault
> > self._raise_error(response, body)
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _
> >
> > response = 
> > detail = 
> >
> > @staticmethod
> > def _raise_error(response, detail=None):
> > """
> > Creates and raises an error containing the details of the given HTTP
> > response and fault.
> >
> > This method is intended for internal use by other components of the
> > SDK. Refrain from using it directly, as backwards compatibility 
> > isn't
> > guaranteed.
> > """
> > fault = detail if isinstance(detail, types.Fault) else None
> >
> > msg = ''
> > if fault:
> > if fault.reason:
> > if msg:
> > msg += ' '
> > msg = msg + 'Fault reason is "%s".' % fault.reason
> > if fault.detail:
> > if msg:
> > msg += ' '
> > msg = msg + 'Fault detail is "%s".' % fault.detail
> > if response:
> > if response.code:
> > if msg:
> > msg += ' '
> > msg = msg + 'HTTP response code is %s.' % response.code
> > if response.message:
> > if msg:
> > msg += ' '
> > msg = msg + 'HTTP response message is "%s".' % 
> > response.message
> >
> > if 

[ovirt-devel] Re: Please resync centos-stream-el8stream/base mirror

[Nir Soffer]

On Wed, Jul 7, 2021 at 11:12 AM Ehud Yonasi  wrote:
>
> Thanks for the report Sandro,
>
> Resyncing again.

Ehud, do we have now centos-stream mirror?

What is the way to specify the mirror in the check-patch.repos file?

Currently we use:
https://github.com/oVirt/vdsm/blob/master/automation/check-patch.repos
https://github.com/oVirt/ovirt-imageio/blob/master/automation/check-patch.repos

> On 7 Jul 2021, at 9:33, Sandro Bonazzola  wrote:
>
> Looks like the mirror needs a re-sync:
>
> [2021-07-07T06:24:14.859Z] [MIRROR] libpmem-1.6.1-1.el8.x86_64.rpm: Status 
> code: 404 for 
> http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Packages/libpmem-1.6.1-1.el8.x86_64.rpm
>  (IP: 66.187.230.49)
> [2021-07-07T06:24:14.859Z] [MIRROR] libpmem-1.6.1-1.el8.x86_64.rpm: Status 
> code: 404 for 
> http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Packages/libpmem-1.6.1-1.el8.x86_64.rpm
>  (IP: 66.187.230.49)
> [2021-07-07T06:24:14.859Z] [MIRROR] libpmem-1.6.1-1.el8.x86_64.rpm: Status 
> code: 404 for 
> http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Packages/libpmem-1.6.1-1.el8.x86_64.rpm
>  (IP: 66.187.230.49)
> [2021-07-07T06:24:14.859Z] [FAILED] libpmem-1.6.1-1.el8.x86_64.rpm: Status 
> code: 404 for 
> http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Packages/libpmem-1.6.1-1.el8.x86_64.rpm
>  (IP: 66.187.230.49)
> [2021-07-07T06:24:14.859Z] Error: Error downloading packages:
> [2021-07-07T06:24:14.859Z]   Status code: 404 for 
> http://mirrors.phx.ovirt.org/repos/yum/centos-stream-el8stream/base/Packages/libpmem-1.6.1-1.el8.x86_64.rpm
>  (IP: 66.187.230.49)
>
> Thanks
> --
> Sandro Bonazzola
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA
>
> sbona...@redhat.com
> Red Hat respects your work life balance. Therefore there is no need to answer 
> this email out of your office hours.
>
>
> ___
> 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/J3X5FHOKXTG2BA7XNBAZ3XWIRVC7PHPN/
>
>
> ___
> 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/QAEMTSN5WTOVMART6N44BUEJEDZZYTPV/
___
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/NXMUFGFG325652L5ASLHAWZGMRBVMRM2/

[ovirt-devel] Re: cloning LVM partitions

[Nir Soffer]

On Tue, Jun 29, 2021 at 9:09 AM Laurent Duparchy  wrote:
...
> This is valuable information. I didn't read it anywhere so far.
> We'll have to evaluate what impact this way of snapshoting has on 
> performances.

Sure, keeping many snapshots is not recommended. You should not
treat snapshots as long term backup, only as a temporary state to make
it easy to revert changes in the vm.

It makes sense to always keep one snapshot for backup purposes. Backup
applications using snapshots use this algorithm:

Day 1:

1. Create temporary snapshot (e.g. backup-1)
2. Backup snapshot backup-1 (e.g. using image transfer API)

Day 2:

1. Create temporary snapshot (e.g. backup-2)
2. Backup snapshot backup-2
3. Delete snapshot backup-1

Day N:

1. Create temporary snapshot (e.g. backup-N)
2. Backup snapshot backup-N
3. Delete snapshot backup-(N-1)

To download snapshot you can use this example:
https://github.com/oVirt/ovirt-engine-sdk/blob/sdk_4.3/sdk/examples/download_disk_snapshots.py

The example is not very good, and it downloads all snapshots instead of one
but you can use it as an example how to create a transfer for disk snapshot.

> Thanks a lot.
>
>
> Allow me one last question before I stop spamming you...
>
> Using virt-v2v for migration from Oracle VM ("raw" files) to KVM, it seems 
> that the "preallocated" option for (iSCSI) LVM volumes is mandatory.

virt-v2v supports converting to format="qcow2" sparse=True. This
should work with
ovirt 4.3, but there is no way to use these options from the UI.

If you convert in two steps:
- from oracle vm to local file
- from local file to ovirt

and if you have recent enough virt-v2v, you should be able to choose the
image format "qcow2" and allocation "sparse".

  -oaSet output allocation mode
  -of  Set output format

One issue with virt-v2v is that it always allocates entire disk, even when
using sparse disk, since it does not how to estimate the size of the disk:
https://github.com/libguestfs/virt-v2v/blob/62c493e314f2d50db54079cd90c0d5a49363139f/v2v/rhv-upload-plugin.py#L490

To shrink the disk size to optimal size, you can reduce the disk after
the import:
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/reduce_disk.py

> We may have to change some currently large volumes to thin-provisionning.
> What would be the fastest way to do that ? (maybe directly, not in a two 
> phases migrations)

I think the simplest way to do this on 4.3 is to create a template from
the vm, and choose qcow2 disk format. When the template is ready,
you can create the vm back from the template, and delete the template.

This requires downtime during the conversion. In 4.4. you can create
a template from a snapshot to avoid the downtime.

We are working on a disk conversion feature for 4.4.9, @Benny Zlotnik
can add more info.

Nir
___
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/CNBKJGR6T75VBWPGUSXNMYNEK3BBXC4N/

[ovirt-devel] Re: cloning LVM partitions

[Nir Soffer]

On Mon, Jun 28, 2021 at 11:07 AM Laurent Duparchy  wrote:
>
> Hi,
>
> Thanks you for your response.
>
> I'm new to ovirt / LVM (Oracle flavor). I'm wondering why LVM snapshots don't 
> have the "s" attribute. ..

We don't use LVM snapshots for VM disks. oVirt snapshots are using
qcow2 logical volumes per
VM snapshots.

For example VM can start with one logical volume:

/dev/vgname/lv-1

When you create a snapshot in engine, ovirt creates new logical volume:

/dev/vgname/lv-2

And creates a qcow2 image using /dev/vgname/lv-1 as the backing file:

/dev/vgname/lv-1 <- /dev/vgname/lv-2 (top)

> ( I noticed it while looking for the best way to backup the VMs to tape.

The best way with oVirt 4.4 is to use incremental backup, but you are
likely using 4.3.

There are several backup solutions that use snapshots to create
incremental backup.
This is more complex and less efficient but it should be available for
your version.

> We must have an offline & out-of-band backup to tape which is part of our 
> "Disaster Recovery Plan".
> At the moment a (most simple) "dd" of the entire Volume Group seems OK. 
> Nevertheless checking if more granular is possible...
> Keeping things simple being a goal. )

Keeping things simple backup at the storage side at the LUN level is
probably the simplest way.
It may also be the most efficient way depending on the storage
capabilities, for example if your
storage supports thin provisioning.

But note that backup in storage level can create inconsistent backup,
so starting a VM after
restore may require running fsck. Using snapshots or incremental
backup should generally
avoid this issue if the VMs have qemu-guest-agent.

Nir

> Laurent Duparchy
> ESRF - The European Synchrotron
> MIS Group
> 04 76 88 22 56 / 06 71 10 38 40
>
> Nir Soffer wrote on 21/06/2021 21:35:
>
> On Mon, Jun 21, 2021 at 10:29 PM  wrote:
>
> Hi,
> What are the internal commands used to clone LVM partitions ?
>
> Are you sure this is the right mailing list?
>
> (you can simply indicate me the source code where this is done)
>
> If you mean how we copy disks lvm based disks (e.g. on FC/iSCSI storage 
> domain),
> we use this:
> https://github.com/oVirt/vdsm/blob/4f728377f6cd6950035a7739014737789a4d6f14/lib/vdsm/storage/qemuimg.py#L232
>
> Most flows uses this API for copying disks:
> https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/sdm/api/copy_data.py
>
> Nir
>
>
___
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/KM4LYDVTCOAUQY2JBLT2NE3DOBR7WCCP/

[ovirt-devel] Re: Broken commit-msg hook in gerrit

[Nir Soffer]

On Fri, Jun 25, 2021 at 10:38 PM Nir Soffer  wrote:
>
> In ovirt-imageio developer docs, we ask to install the commit-msg hook
> from gerrit:
>
> wget -P .git/hooks https://gerrit.ovirt.org/tools/hooks/commit-msg
>
> This downloads now a broken script that does not add a ChangeId header.

I found the issue, our instructions were missing:

chmod +x .git/hooks/commit-msg

After adding it, the new script works fine.

> In the past I think it returned something like the attached file,
> without the code for
> adding signed-off-by.
>
> I suggest to replace the current file at:
> https://gerrit.ovirt.org/tools/hooks/commit-msg
>
> Or if we want to keep the default file for some reason, add:
> https://gerrit.ovirt.org/tools/ovirt/hooks/commit-msg
>
> This file contains the code for adding the signed-off-by header, so so
> developers
> do not need to add this manually:
>
> # Add Signed-off-by trailer.
> sob=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: 
> \1/p')
> git interpret-trailers --in-place --trailer "$sob" "$1"

But developers still need to add the code above.

Attaching a version with this code to replace the current file.


commit-msg
Description: Binary data
___
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/HIKFHKBDSOY3SBKMKMTUY6TKGTSOUPKK/

[ovirt-devel] Broken commit-msg hook in gerrit

[Nir Soffer]

In ovirt-imageio developer docs, we ask to install the commit-msg hook
from gerrit:

wget -P .git/hooks https://gerrit.ovirt.org/tools/hooks/commit-msg

This downloads now a broken script that does not add a ChangeId header.

In the past I think it returned something like the attached file,
without the code for
adding signed-off-by.

I suggest to replace the current file at:
https://gerrit.ovirt.org/tools/hooks/commit-msg

Or if we want to keep the default file for some reason, add:
https://gerrit.ovirt.org/tools/ovirt/hooks/commit-msg

This file contains the code for adding the signed-off-by header, so so
developers
do not need to add this manually:

# Add Signed-off-by trailer.
sob=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')
git interpret-trailers --in-place --trailer "$sob" "$1"

Later we need to replace this ugly shell script with proper code.

Nir


commit-msg
Description: Binary data
___
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/VWWHRRTU3TBCIRIBRZLMYAIRGK2Q2KMM/

[ovirt-devel] Re: Add "ci system-test" command

[Nir Soffer]

On Thu, Jun 24, 2021 at 1:49 PM Marcin Sobczyk  wrote:
>
>
>
> On 6/23/21 5:44 PM, Nir Soffer wrote:
> > Similar to "ci build", "ci test", "ci merge" add a new command that
> > triggers OST run.
> >
> > Running OST is tied now in vdsm (and engine?) to Code-Review: +2.
> > This causes trouble and does not allow non-maintainers to use the 
> > convenient OST
> > infrastructure.
> >
> > Expected flow:
> >
> > 1. User add a comment with "ci system-test"
> "ci system-test" is sooo long, I vote for "ci ost".

Works for me, but "system-test" is more consistent with other ci commands:
https://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerrit/index.html#manual-functionality-of-the-ovirt-ci-system
___
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/QB4JJYTZVLL2CWV6Z3SR37R5JLSL4X6S/

[ovirt-devel] Re: Add "ci system-test" command

[Nir Soffer]

On Thu, Jun 24, 2021 at 2:11 PM Yedidyah Bar David  wrote:
>
> On Thu, Jun 24, 2021 at 1:51 PM Marcin Sobczyk  wrote:
> >
> >
> >
> > On 6/23/21 5:44 PM, Nir Soffer wrote:
> > > Similar to "ci build", "ci test", "ci merge" add a new command that
> > > triggers OST run.
> > >
> > > Running OST is tied now in vdsm (and engine?) to Code-Review: +2.
> > > This causes trouble and does not allow non-maintainers to use the 
> > > convenient OST
> > > infrastructure.
> > >
> > > Expected flow:
> > >
> > > 1. User add a comment with "ci system-test"
> > "ci system-test" is sooo long, I vote for "ci ost".
>
> +1.
>
> Perhaps we can add an optional suite name? E.g. 'ci ost ansible-suite-master'

+1
___
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/SKS3XFCIC6SUPAWV52XMRFQP2CXXLHXG/

[ovirt-devel] Add "ci system-test" command

[Nir Soffer]

Similar to "ci build", "ci test", "ci merge" add a new command that
triggers OST run.

Running OST is tied now in vdsm (and engine?) to Code-Review: +2.
This causes trouble and does not allow non-maintainers to use the convenient OST
infrastructure.

Expected flow:

1. User add a comment with "ci system-test"
2. OST flow building and running OST triggered
___
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/2FCJZLFJJ2SB3KVQ3YREZBVEYXPBQRUN/

[ovirt-devel] Add OST flag to all oVirt projects

[Nir Soffer]

Similar to Continuous-Integration flag, OST needs its own flag.

OST will set this flag when OST build started from gerrit was started.

We want to make this field mandatory for merging patches, like
Continuous-Integration.

Like Continuous-Integration maintainers should be able to override the
value after
OST completed, or set the value before OST started.
___
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/XAB7EMWSX7VEQ7UMMBLTRLL2ND4LGSRM/

[ovirt-devel] Re: oVirt CI mirror for centos stream advancedvirt-common repo

[Nir Soffer]

On Fri, Jun 11, 2021 at 12:41 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno ven 4 giu 2021 alle ore 19:44 Nir Soffer 
> ha scritto:
>
>> I updated vdsm libvirt requirement to 7.0.0-14. The package exists in
>> centos
>> stream and rhel so the change is correct, but the install check fails in
>> the CI.
>>
>> I found that adding the repo to check-patch.repos works:
>> https://gerrit.ovirt.org/c/vdsm/+/115039/4/automation/check-patch.repos
>>
>> But depending on mirror.centos.org does not feel like the right way. I
>> think
>> keeping a local mirror is the right way.
>>
>
> Please note that despite we are pointing to centos mirrors, CI is running
> under proxy, so we are caching on our datacenter the rpms we consume anyway.
> That said, we can mirror advanced virtualization repos as well and the
> local mirror will be automatically picked up.
>
> I see we are already mirroring the test repo for CentOS Linux:
> ./data/mirrors-reposync.conf:
>70 : [ovirt-master-centos-advanced-virtualization-el8]
>72 : baseurl=
> https://buildlogs.centos.org/centos/8/virt/x86_64/advanced-virtualization/
>
> For CentOS Stream we'll need an addition there. Please open a ticket on
> infra-supp...@ovirt.org about it.
>

Trying


>
>
>
>> It looks like the stdci docs[1] are not maintained for a while,
>> listing mirrors for
>> fedora 30 and centos 7.
>>
>
> I would suggest to open a ticket for this as well
>
>
>
>>
>> Looking in the mirrors jobs[2] we have advanced-virtualization for
>> centos[3] but
>> it holds old versions (6.x).
>>
>> Can we add a local mirror for this repo?
>>
>> [1]
>> https://ovirt-infra-docs.readthedocs.io/en/latest/CI/List_of_mirrors/index.html
>> [2] https://jenkins.ovirt.org/search/?q=system-sync_mirrors
>> [3]
>> https://buildlogs.centos.org/centos/8/virt/x86_64/advanced-virtualization/Packages/l/
>>
>> Nir
>>
>>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://www.redhat.com/>
>
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> <https://mojo.redhat.com/docs/DOC-1199578>*
>
>
>
___
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/2KHM7WWSSFPT5UYC3YX3P3R5EOKMOAKM/

[ovirt-devel] Re: cloning LVM partitions

[Nir Soffer]

On Mon, Jun 21, 2021 at 10:29 PM  wrote:
>
> Hi,
> What are the internal commands used to clone LVM partitions ?

Are you sure this is the right mailing list?

> (you can simply indicate me the source code where this is done)

If you mean how we copy disks lvm based disks (e.g. on FC/iSCSI storage domain),
we use this:
https://github.com/oVirt/vdsm/blob/4f728377f6cd6950035a7739014737789a4d6f14/lib/vdsm/storage/qemuimg.py#L232

Most flows uses this API for copying disks:
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/sdm/api/copy_data.py

Nir
___
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/YI7LQQBB5U2UMXF75RUCX2NQVFGNR4X5/

[ovirt-devel] Re: AV 8.4 for CentOS Linux

[Nir Soffer]

On Mon, Jun 21, 2021 at 8:39 PM Marcin Sobczyk  wrote:
>
>
>
> On 6/20/21 12:23 PM, Dana Elfassy wrote:
> > Hi,
> > I'm getting packages conflicts when trying to upgrade my Centos8.4 and
> > Centos-Stream hosts.
> > (Centos Stream was installed from iso, then I
> > installed ovirt-release-master.rpm and deployed the host)
> > The details below are the output for Centos-Stream
> > * The packages conflicts occur also on OST -
> > https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ds-ost-baremetal_manual/7211/console
> > 
> >
> > Do you know what could've caused this and how it can be fixed?
> Yes, libvirt 7.4.0 + qemu-kvm 6.0.0 is currently broken and has bugs
> filed on it.
> We're trying to avoid these packages by excluding them on vdsm's spec
> level [1]
> and downgrading to older versions (7.0.0 and 5.2.0 respectively) that
> work in OST [2].
> Unfortunately somewhere around late Friday a new version of qemu-kvm
> was published, which makes the downgrade process go from 6.0.0-19 to
> 6.0.0-18
> and not the 5.2.0 that works. We don't have a reasonable resolution for
> OST yet.
>
> If you manage your host manually simply 'dnf downgrade qemu-kvm' until
> you get version 5.2.0
> or download and install all the older RPMs manually.

This was true this morning, but we reverted the patch conflicting with
libvirt 7.4.0. Please use the latest vdsm from master.

You can build vdsm locally or use this repo:
https://jenkins.ovirt.org/job/vdsm_standard-on-merge/3659/artifact/build-artifacts.build-py3.el8stream.x86_64/

Nir

> Regards, Marcin
>
> [1] https://gerrit.ovirt.org/#/c/vdsm/+/115193/
> [2] https://gerrit.ovirt.org/#/c/ovirt-system-tests/+/115194/
>
> > Thanks,
> > Dana
> >
> > [root@localhost ~]# rpm -q vdsm
> > vdsm-4.40.70.4-5.git73fbe23cd.el8.x86_64
> >
> > [root@localhost ~]# dnf module list virt
> > Last metadata expiration check: 1:09:54 ago on Sun 20 Jun 2021
> > 05:09:50 AM EDT.
> > CentOS Stream 8 - AppStream
> > Name  Stream   Profiles  Summary
> > virt  rhel [d][e]common
> > [d]  Virtualization module
> >
> > The error:
> > [root@localhost ~]# dnf update
> > Last metadata expiration check: 1:08:13 ago on Sun 20 Jun 2021
> > 05:09:50 AM EDT.
> > Error:
> >  Problem 1: package vdsm-4.40.70.4-5.git73fbe23cd.el8.x86_64 requires
> > (libvirt-daemon-kvm >= 7.0.0-14 and libvirt-daemon-kvm < 7.4.0-1), but
> > none of the providers can be installed
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-7.0.0-14.1.el8.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-6.0.0-35.module_el8.5.0+746+bbd5d70c.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-6.0.0-36.module_el8.5.0+821+97472045.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-5.6.0-10.el8.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-6.0.0-17.el8.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-6.0.0-25.2.el8.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-6.6.0-13.el8.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-6.6.0-7.1.el8.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-6.6.0-7.3.el8.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-7.0.0-13.el8s.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.4.0-1.el8s.x86_64 and
> > libvirt-daemon-kvm-7.0.0-14.el8s.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.0.0-13.el8s.x86_64 and
> > libvirt-daemon-kvm-7.4.0-1.el8s.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.0.0-14.el8s.x86_64 and
> > libvirt-daemon-kvm-7.4.0-1.el8s.x86_64
> >   - cannot install both libvirt-daemon-kvm-7.0.0-9.el8s.x86_64 and
> > libvirt-daemon-kvm-7.4.0-1.el8s.x86_64
> >   - cannot install the best update candidate for package
> > vdsm-4.40.70.4-5.git73fbe23cd.el8.x86_64
> >   - cannot install the best update candidate for package
> > libvirt-daemon-kvm-7.0.0-14.1.el8.x86_64
> >  Problem 2: problem with installed package
> > vdsm-4.40.70.4-5.git73fbe23cd.el8.x86_64
> >   - package vdsm-4.40.70.4-5.git73fbe23cd.el8.x86_64 requires
> > (qemu-kvm >= 15:5.2.0 and qemu-kvm < 15:6.0.0), but none of the
> > providers can be installed
> >   - cannot install both qemu-kvm-15:6.0.0-19.el8s.x86_64 and
> > qemu-kvm-15:5.2.0-16.el8s.x86_64
> >   - cannot install both qemu-kvm-15:6.0.0-19.el8s.x86_64 and
> > qemu-kvm-15:4.2.0-48.module_el8.5.0+746+bbd5d70c.x86_64
> >   - cannot install both qemu-kvm-15:6.0.0-19.el8s.x86_64 

[ovirt-devel] Re: OST verifed -1 broken, fails for infra issue in OST

[Nir Soffer]

On Mon, Jun 21, 2021 at 7:30 PM Michal Skrivanek
 wrote:
>
>
>
> > On 14. 6. 2021, at 13:14, Nir Soffer  wrote:
> >
> > I got this wrong review from OST, which looks like an infra issue in OST:
> >
> > Patch:
> > https://gerrit.ovirt.org/c/vdsm/+/115232
> >
> > Error:
> > https://gerrit.ovirt.org/c/vdsm/+/115232#message-46ad5e75_ed543485
> >
> > Failing code:
> >
> > Package(*line.split()) for res in results.values() > for line in
> > _filter_results(res['stdout'].splitlines()) ] E TypeError: __new__()
> > missing 2 required positional arguments: 'version' and 'repo'
> > ost_utils/ost_utils/deployment_utils/package_mgmt.py:177: TypeError
> >
> > I hope someone working on OST can take a look soon.
>
> it’s from a week ago, is that still relevant or you pasted a wrong patch?

Yes, this was sent 7 days ago, and Marcin already answered on the same day.

For some reason the mailing list sent this mail to subscribers only today.
___
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/W23P7MC7POMAAJR5UBK3MU6D3MNHOOJ6/

[ovirt-devel] Re: libvirtError: internal error: unknown feature amd-sev-es

[Nir Soffer]

I'm using RHEL AV 8.5.0 nightly repos without any issue.

$ rpm -q libvirt-daemon vdsm
libvirt-daemon-7.3.0-1.module+el8.5.0+11004+f4810536.x86_64
vdsm-4.40.70.3-202106131544.git9b5c96716.el8.x86_64

Nir
___
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/KUGN3VQLZBX2JSJE6JXQULD3YJLS257O/

[ovirt-devel] Re: Purging inactive maintainers from vdsm-master-maintainers

[Nir Soffer]

On Mon, Jun 21, 2021 at 12:09 PM Milan Zamazal  wrote:
>
> Nir Soffer  writes:
>
> > On Mon, Jun 21, 2021 at 11:35 AM Milan Zamazal  wrote:
> >>
> >> Edward Haas  writes:
> >
> >>
> >> > On Sun, Jun 20, 2021 at 11:29 PM Nir Soffer  wrote:
> >> >
> >> >> On Mon, Dec 2, 2019 at 4:27 PM Adam Litke  wrote:
> >> >>
> >> >>> I also agree with the proposal.  It's sad to turn in my keys but I'm
> >> >>> likely unable to perform many duties expected of a maintainer at this
> >> >>> point.  I know that people can still find me via the git history :)
> >> >>>
> >> >>> On Thu, Nov 28, 2019 at 3:37 AM Milan Zamazal 
> >> >>> wrote:
> >> >>>
> >> >>>> Dan Kenigsberg  writes:
> >> >>>>
> >> >>>> > On Wed, Nov 27, 2019 at 4:33 PM Francesco Romani 
> >> >>>> > 
> >> >>>> wrote:
> >> >>>> >>
> >> >>>> >> On 11/27/19 3:25 PM, Nir Soffer wrote:
> >> >>>> >
> >> >>>> >> > I want to remove inactive contributors from 
> >> >>>> >> > vdsm-master-maintainers.
> >> >>>> >> >
> >> >>>> >> > I suggest the simple rule of 2 years of inactivity for removing 
> >> >>>> >> > from
> >> >>>> >> > this group,
> >> >>>> >> > based on git log.
> >> >>>> >> >
> >> >>>> >> > See the list below for current status:
> >> >>>> >> > https://gerrit.ovirt.org/#/admin/groups/106,members
> >> >>>> >>
> >> >>>> >>
> >> >>>> >> No objections, keeping the list minimal and current is a good idea.
> >> >>>> >
> >> >>>> >
> >> >>>> > I love removing dead code; I feel a bit different about removing old
> >> >>>> > colleagues. Maybe I'm just being nostalgic.
> >> >>>> >
> >> >>>> > If we introduce this policy (which I understand is healthy), let us
> >> >>>> > give a long warning period (6 months?) before we apply the policy to
> >> >>>> > existing dormant maintainers. We should also make sure that we
> >> >>>> > actively try to contact a person before he or she is dropped.
> >> >>>>
> >> >>>> I think this is a reasonable proposal.
> >> >>>>
> >> >>>> Regards,
> >> >>>> Milan
> >> >>>>
> >> >>>
> >> >> I forgot about this, and another year passed.
> >> >>
> >> >> Sending again, this time I added all past maintainers that may not watch
> >> >> this list.
> >> >>
> >> >
> >> > Very sad, but it makes total sense. +1
> >> > Note that other projects move past maintainers to a special group named
> >> > "emeritus_*".
> >>
> >> Not a bad idea, I think we could have such a group in Vdsm too.
> >
> > It would be nice but not part of gerrit permission configuration.
> >
> > We have an AUTHORS file, last updated in 2013. We can use this file
> > to give credit to past maintainers.
>
> AUTHORS is a better place to give credits, but the group could be also
> useful as a more reliable tracking past maintainers and in case of
> restoring maintainer rights, if such a need ever occurs.  (Yes, no way
> necessary for that but maybe nice to have.)

Gerrit has an audit log:
https://gerrit.ovirt.org/admin/groups/106,audit-log

If you don't trust it, we can add a file with this info in the project.

If we look at other projects, qemu has this file:
https://github.com/qemu/qemu/blob/master/MAINTAINERS
___
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/4WFAUGBWL4WLGIGA6INYGG3OQR2MKSBB/

[ovirt-devel] Re: Purging inactive maintainers from vdsm-master-maintainers

[Nir Soffer]

On Mon, Dec 2, 2019 at 4:27 PM Adam Litke  wrote:

> I also agree with the proposal.  It's sad to turn in my keys but I'm
> likely unable to perform many duties expected of a maintainer at this
> point.  I know that people can still find me via the git history :)
>
> On Thu, Nov 28, 2019 at 3:37 AM Milan Zamazal  wrote:
>
>> Dan Kenigsberg  writes:
>>
>> > On Wed, Nov 27, 2019 at 4:33 PM Francesco Romani 
>> wrote:
>> >>
>> >> On 11/27/19 3:25 PM, Nir Soffer wrote:
>> >
>> >> > I want to remove inactive contributors from vdsm-master-maintainers.
>> >> >
>> >> > I suggest the simple rule of 2 years of inactivity for removing from
>> >> > this group,
>> >> > based on git log.
>> >> >
>> >> > See the list below for current status:
>> >> > https://gerrit.ovirt.org/#/admin/groups/106,members
>> >>
>> >>
>> >> No objections, keeping the list minimal and current is a good idea.
>> >
>> >
>> > I love removing dead code; I feel a bit different about removing old
>> > colleagues. Maybe I'm just being nostalgic.
>> >
>> > If we introduce this policy (which I understand is healthy), let us
>> > give a long warning period (6 months?) before we apply the policy to
>> > existing dormant maintainers. We should also make sure that we
>> > actively try to contact a person before he or she is dropped.
>>
>> I think this is a reasonable proposal.
>>
>> Regards,
>> Milan
>>
>
I forgot about this, and another year passed.

Sending again, this time I added all past maintainers that may not watch
this list.

Nir
___
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/Z36S3OSDKGEB7JYGDPKT3IFDSPS7GFVY/

[ovirt-devel] Moving #vdsm to #ovirt?

[Nir Soffer]

We had mostly dead #vdsm channel in freenode[1].

Recently there was a hostile takeover of freenode, and old freenode
folks created
libera[2] network. Most (all?) projects moved to this network.

We can move #vdsm to libera, but I think we have a better option, use
#ovirt channel
in oftc[3], which is pretty lively.

Having vdsm developers in #ovirt channel is good for the project and
will make it easier
to reach developers.

Moving to libera require registration work. Moving to #ovirt requires no change.
In both cases we need to update vdsm readme and ovirt.org.

What do you think?

[1] https://freenode.net/
[2] https://libera.chat/
[3] https://www.oftc.net/

Nir
___
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/LXMSZSA3SKMYV36OJMPC65CI4S2WQZ3U/