[ovirt-devel] Re: Error: Adding new Host to ovirt-engine

[Yedidyah Bar David]

Hi,

Sorry, but I do not follow oVirt development closely anymore.

I guess it's due to a newer ansible (-core) using a newer python which
is missing some of our dependencies - see also e.g.:

https://github.com/oVirt/ovirt-engine/pull/826

Not sure about current status.

You might try to work around this by downgrading ansible-core on the
engine machine, until this is fixed.

Best regards,

On Tue, Apr 4, 2023 at 1:05 PM James Wadsworth
 wrote:
>
> Hi Didi, we are exactly in the same situation. We are running ovirt 4.5.4 on 
> all hosts. We did a backup of the ovirt-engine, when we then chose one of our 
> 3 hosts to redeploy the ovirt-engine. On the host for the redeploy we have 
> the ovirt-engine running correctly. However when we try reinstall other two 
> hosts to add them back into the cluster we encounter the same error.
>
> FAILED! => {\"msg\": \"The conditional check 'cluster_switch == \\\"ovs\\\" 
> or (ovn_central is defined and ovn_central | ipaddr)' failed. The error was: 
> The ipaddr filter requires python's netaddr be installed on the ansible 
> controller\\n\\nThe error appears to be in 
> '/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-provider-ovn-driver/tasks/configure.yml':
>  line 3, column 5, but may\\nbe elsewhere in the file depending on the exact 
> syntax problem.\\n\\nThe offending line appears to be:\\n\\n- block:\\n  - 
> name: Install ovs\\n^ here\\n\"}",
>
> We have the hosts running RHEL 8.7. The self hosted engine is runing on 
> Centos Stream 8. Before we redeployed the ovirt-engine, the ovirt was running 
> on RHEL 8.7 which we had previously migrated from Centos 8.4.
>
> On the engine we have the following:
> # ansible --version
> ansible [core 2.14.2]
>   config file = /etc/ansible/ansible.cfg
>   configured module search path = ['/root/.ansible/plugins/modules', 
> '/usr/share/ansible/plugins/modules']
>   ansible python module location = /usr/lib/python3.11/site-packages/ansible
>   ansible collection location = 
> /root/.ansible/collections:/usr/share/ansible/collections
>   executable location = /usr/bin/ansible
>   python version = 3.11.2 (main, Feb 28 2023, 23:00:48) [GCC 8.5.0 20210514 
> (Red Hat 8.5.0-18)] (/usr/bin/python3.11)
>   jinja version = 3.1.2
>   libyaml = True
>
> # pip3 --version
> pip 9.0.3 from /usr/lib/python3.6/site-packages (python 3.6)
>
> python3.6 -m pip list
> DEPRECATION: The default format will switch to columns in the future. You can 
> use --format=(legacy|columns) (or define a format=(legacy|columns) in your 
> pip.conf under the [list] section) to disable this warning.
> alembic (1.7.1)
> amqp (5.0.9)
> attrs (17.4.0)
> automaton (2.5.0)
> Babel (2.5.1)
> bcrypt (3.1.7)
> beautifulsoup4 (4.9.3)
> boto3 (1.6.1)
> botocore (1.17.52)
> Bottleneck (1.2.1)
> cachetools (4.2.0)
> ceph (1.0.0)
> cephfs (2.0.0)
> cffi (1.13.2)
> chardet (3.0.4)
> cinder (20.1.0)
> cinderlib (4.2.0)
> configobj (5.0.6)
> configshell-fb (1.1.28)
> cryptography (3.2.1)
> cssselect (0.9.2)
> cycler (0.10.0)
> dbus-python (1.2.4)
> debtcollector (2.5.0)
> decorator (4.4.0)
> distro (1.4.0)
> dnspython (1.15.0)
> docutils (0.14)
> eventlet (0.33.0)
> extras (1.0.0)
> fasteners (0.14.1)
> file-magic (0.3.0)
> fixtures (3.0.0)
> fluidity-sm (0.2.0)
> futurist (2.4.0)
> gpg (1.13.1)
> greenlet (0.4.13)
> html5lib (0.9)
> httplib2 (0.16.0)
> idna (2.5)
> importlib-metadata (1.7.0)
> importlib-resources (4.1.1)
> invoke (1.4.0)
> isc (2.0)
> iso8601 (0.1.12)
> Jinja2 (2.10.1)
> jmespath (0.9.0)
> jsonpatch (1.21)
> jsonpointer (1.10)
> jsonschema (3.2.0)
> kazoo (2.8.0)
> kiwisolver (1.1.0)
> kmod (0.1)
> kombu (5.0.2)
> lexicon (1.0.0)
> libcomps (0.1.18)
> lockfile (0.12.2)
> lxml (4.2.3)
> Mako (1.0.6.dev0)
> MarkupSafe (0.23)
> matplotlib (3.1.1)
> mock (3.0.5)
> msgpack (1.0.3)
> netaddr (0.7.19)
> netifaces (0.10.6)
> networkx (2.5)
> nftables (0.1)
> numexpr (2.7.1)
> numpy (1.14.3)
> nvmetcli (0.7)
> oauthlib (2.1.0)
> os-brick (5.2.2)
> os-win (5.6.0)
> oslo.concurrency (4.5.0)
> oslo.config (8.8.0)
> oslo.context (4.1.0)
> oslo.db (11.2.0)
> oslo.i18n (5.1.0)
> oslo.log (4.7.0)
> oslo.messaging (12.13.0)
> oslo.metrics (0.4.0)
> oslo.middleware (4.5.1)
> oslo.privsep (2.7.0)
> oslo.rootwrap (6.3.1)
> oslo.serialization (4.3.0)
> oslo.service (2.8.0)
> oslo.utils (4.12.3)
> oslo.versionedobjects (2.6.0)
> ovirt-engine-sdk-python (4.6.0)
> ovirt-imageio (2.4.7)
> ovs (2.15.8)
> ovsdbapp (1.15.3)
> packaging (20.4)
> pandas (0.25.3)
> paramiko (2.7.2)
> passlib (1.7.4)
> Paste (3.5.0)
> PasteDeploy (2.1.1)
> pbr (5.5.1)
> perf (0.1)
> pexpect (4.7.0)
> Pillow (5.1.1)
> pip (9.0.3)
> ply (3.9)
> prettytable (0.7.2)
> prometheus-client (0.7.1)
> psutil (5.7.3)
> psycopg2 (2.8.6)
> ptyprocess (0.5.2)
> pwquality (1.4.4)
> pyasn1 (0.4.6)
> pyasn1-modules (0.2.6)
> pycairo (1.16.3)
> pycparser (2.14)
> pycurl (7.43.0.2)
> pydbus (0.6.0)
> pydot (1.4.1)
> pygobject (3.28.3)
> pygraphviz (1.5)
> pyinotify (0.9.6)
> PyJWT 

[ovirt-devel] Re: Installation of Ubuntu 22.04 on my Ovirt

[Yedidyah Bar David]

On Thu, Nov 10, 2022 at 12:19 PM Rob Linden  wrote:
>
> Hello!
> I'm not sure if it's _possible_ to install oVirt on Ubuntu, but it isn't 
> supported:

There were efforts, several years ago, on porting oVirt to
Debian/Ubuntu. I do not think this ever matured enough for general
use. See also e.g. these, and note that they are all old and
unmaintained:

https://www.ovirt.org/develop/developer-guide/ubuntu.html

https://www.ovirt.org/develop/developer-guide/vdsm/on-debian.html

https://www.ovirt.org/develop/developer-guide/vdsm/on-ubuntu.html

> https://www.ovirt.org/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/#operating-system-requirements_SHE_cli_deploy
> There are older tutorials that claim it works, like 
> https://blog.eldernode.com/install-and-configure-ovirt-on-ubuntu-20-04/

From quick skimming, it seems like the above post describes how to
install an Ubuntu _VM_ inside an existing oVirt setup (which itself
does not run on Ubuntu - or at least, the post does not discuss that).

> I have not tried that.
> What You could do (and which is what I do, although not on Ubuntu) is to run 
> a virtual machine with qemu/KVM and on that VM You'd install CentOS Stream 
> and there You can install and run oVirt. I think that might be easier and/or 
> more reliable (because it's tested better) than getting oVirt to run directly 
> on Ubuntu.

That's currently the best option for learning/playing/testing.

Good luck and best regards,
-- 
Didi
___
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/JMFAUAHGPCDCUT2W4QO67IXWIGT7NTXB/

[ovirt-devel] Re: separate DWH/grafana machine with keycloak enabled

[Yedidyah Bar David]

On Mon, Oct 24, 2022 at 10:31 AM Yedidyah Bar David  wrote:
>
> Hi all,
>
> $Subject is currently broken.
>
> We do not have yet an open bug for this but did have a few related
> (but different) ones, including:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2122174
> https://bugzilla.redhat.com/show_bug.cgi?id=2113980
>
> While looking at this, I decided it's about time to have
> ovirt-system-tests test this flow, as it seems it's not tested enough
> otherwise.
>
> Right now, I managed to make it all work, but do have some open
> questions, thus current email.
>
> What I have right now
> =
> 1. This harmless patch to the engine, to just add new library code,
> only to be used (for now) by grafana setup code (later):
>
> https://github.com/oVirt/ovirt-engine/pull/669
>
> I see no obvious reason to not merge it already, but if it turns out
> that only grafana setup is going to ever use it, it might be easier to
> move this code there. In principle it can be useful also for OVN, as
> commented there.
>
> 2. This patch to DWH. It's "mandatory", but not enough to get a
> complete solution. Should be ready for merge. Requires above engine
> patch.
>
> https://github.com/oVirt/ovirt-dwh/pull/57
>

I also ran basic-suite on the two of them together - that's just
a sanity test, the patches should mostly be irrelevant on the same
machine - and it passed, so I think we can merge them. As noted,
this isn't enough.

https://redir.apps.ovirt.org/dj/job/ds-ost-baremetal_manual/56399/

> 3. This PR for ovirt-system-tests:
>
> https://github.com/oVirt/ovirt-system-tests/pull/293
>
> What's inside:
>
> 3.1. "Make grafana test use grafana_fqdn" - should be trivial and harmless.
>
> 3.2. "WIP: Add separate-machine-basic-suite-master" - started as a
> copy of basic-suite-master. Much of it is links to there. To review
> the rest, you can compare with relevant files in basic-suite. "WIP",
> because it's not enough, see later, but is probably more-or-less also
> ready for merging.
>
> 3.3. "WIP: Add the dwh/grafana host name to keycloak redirect URIs" -
> this is where my main question/issue is. Without this, our setup code
> sets redirectUris to point only at the engine machine, so when trying
> to login to grafana with SSO, you get an error from keycloak, e.g. as
> in:
>
> https://stackoverflow.com/questions/51275797/invalid-redirect-uri-keycloak-when-client-is-not-on-localhost
>
> When configuring things manually, it's up to the user to handle all of
> this. This applies either to oVirt users that want to do this
> manually, or to RHV users, where keycloak is not integrated:
>
> https://blogs.ovirt.org/2019/01/federate-ovirt-engine-authentication-to-openid-connect-infrastructure/
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html-single/administration_guide/index#Configuring_RHSSO_ldap
>
> So it sounds like it makes sense to fix this in dwh/grafana setup
> code, not in OST, right? But this is slightly more risky and annoying,
> as we'll need to prompt asking the user for the keycloak admin
> password. Perhaps we do want to do this anyway, but perhaps it's
> enough to document how to do this manually (and keep this patch in OST
> as an implementation of this document).
>
> 3.4. "WIP: Copy test_verify_engine_certs to test_001" not sure I
> always needed it, but should be harmless. Perhaps should be done more
> nicely somehow also for other suites.
>
> Opinions/comments/ideas/suggestions/whatever are most welcome!
>
> Thanks and best regards,
> --
> Didi



-- 
Didi
___
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/IODRRQLAWL5DR6QFDAWAECPEEXKBIFVI/

[ovirt-devel] Re: Error: Adding new Host to ovirt-engine

[Yedidyah Bar David]

On Mon, Oct 24, 2022 at 12:29 PM  wrote:
>
> I have the same error in logfile:
> /var/log/ovirt-hosted-engine-setup/engine-logs-2022-10-04T12\:40\:28Z/log/ovirt-engine/host-deploy/ovirt-host-deploy-ansible-20221004150708-host-01.ovirt.management.x-92192810-b1c0-4e6d-b2c6-c21d58daa012.log
>
> FAILED! => {\"msg\": \"The conditional check 'cluster_switch == \\\"ovs\\\" 
> or (ovn_central is defined and ovn_central | ipaddr)' failed. The error was: 
> The ipaddr filter requires python's netaddr be installed on the ansible 
> controller\\n\\nThe error appears to be in 
> '/usr/share/ovirt-engine/ansible-runner-service-project/project/roles/ovirt-provider-ovn-driver/tasks/configure.yml':
>  line 3, column 5, but may\\nbe elsewhere in the file depending on the exact 
> syntax problem.\\n\\nThe offending line appears to be:\\n\\n- block:\\n  - 
> name: Install ovs\\n^ here\\n\"}",
>
> But I have a standard out-of-the-box clean install of a oVirt Node host, 
> using the CentOS Stream 8 based ISO of oVirt version 4.5.2. Once I run 
> hosted-engine --deploy --4, everything is fine, until it comes to Wait for 
> the host to be up where the install stops with error Host is not up, please 
> check logs, perhaps also on the engine machine.

What version of ovirt-engine-appliance do you have there?

>
> No custom configuration of any kind, just following the documentation to get 
> a new cluster up and running. So how do I fix this?

I think it's due to having ansible-core-2.13 on the engine. Should not
happen with the latest versions.

Best regards,
--
Didi
___
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/WNOO7PFBR7ANQCEMPFW2AVXRCXCR3LC3/

[ovirt-devel] Re: GWT in project ovirt

[Yedidyah Bar David]

Hi,

On Mon, Oct 24, 2022 at 12:28 PM  wrote:
>
> Hello!
> I plan to develop ui plugins.

Good luck. I am not a UI person, myself, replying anyway.

> Does it make sense to use GWT?
> Do you plan to use GWT in the project in the future?

I do not think so.

> Do you plan to switch to another technology?

It seems like we already moved to JavaScript.

> If something has already been written about this or there is a roadmap, I ask 
> for a link.

See also:

https://www.ovirt.org/develop/release-management/features/ux/uiplugins43.html

https://lists.ovirt.org/archives/list/us...@ovirt.org/thread/L5B2NGLZCJNWOWKEBKXVSXILR547PJUU/

https://github.com/oVirt/ovirt-web-ui/

https://github.com/oVirt/ovirt-engine-ui-extensions

Best regards,
-- 
Didi
___
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/VMHYU2UVKMCYWMQ4MGJK2JFCRQC5344I/

[ovirt-devel] separate DWH/grafana machine with keycloak enabled

[Yedidyah Bar David]

Hi all,

$Subject is currently broken.

We do not have yet an open bug for this but did have a few related
(but different) ones, including:

https://bugzilla.redhat.com/show_bug.cgi?id=2122174
https://bugzilla.redhat.com/show_bug.cgi?id=2113980

While looking at this, I decided it's about time to have
ovirt-system-tests test this flow, as it seems it's not tested enough
otherwise.

Right now, I managed to make it all work, but do have some open
questions, thus current email.

What I have right now
=
1. This harmless patch to the engine, to just add new library code,
only to be used (for now) by grafana setup code (later):

https://github.com/oVirt/ovirt-engine/pull/669

I see no obvious reason to not merge it already, but if it turns out
that only grafana setup is going to ever use it, it might be easier to
move this code there. In principle it can be useful also for OVN, as
commented there.

2. This patch to DWH. It's "mandatory", but not enough to get a
complete solution. Should be ready for merge. Requires above engine
patch.

https://github.com/oVirt/ovirt-dwh/pull/57

3. This PR for ovirt-system-tests:

https://github.com/oVirt/ovirt-system-tests/pull/293

What's inside:

3.1. "Make grafana test use grafana_fqdn" - should be trivial and harmless.

3.2. "WIP: Add separate-machine-basic-suite-master" - started as a
copy of basic-suite-master. Much of it is links to there. To review
the rest, you can compare with relevant files in basic-suite. "WIP",
because it's not enough, see later, but is probably more-or-less also
ready for merging.

3.3. "WIP: Add the dwh/grafana host name to keycloak redirect URIs" -
this is where my main question/issue is. Without this, our setup code
sets redirectUris to point only at the engine machine, so when trying
to login to grafana with SSO, you get an error from keycloak, e.g. as
in:

https://stackoverflow.com/questions/51275797/invalid-redirect-uri-keycloak-when-client-is-not-on-localhost

When configuring things manually, it's up to the user to handle all of
this. This applies either to oVirt users that want to do this
manually, or to RHV users, where keycloak is not integrated:

https://blogs.ovirt.org/2019/01/federate-ovirt-engine-authentication-to-openid-connect-infrastructure/

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html-single/administration_guide/index#Configuring_RHSSO_ldap

So it sounds like it makes sense to fix this in dwh/grafana setup
code, not in OST, right? But this is slightly more risky and annoying,
as we'll need to prompt asking the user for the keycloak admin
password. Perhaps we do want to do this anyway, but perhaps it's
enough to document how to do this manually (and keep this patch in OST
as an implementation of this document).

3.4. "WIP: Copy test_verify_engine_certs to test_001" not sure I
always needed it, but should be harmless. Perhaps should be done more
nicely somehow also for other suites.

Opinions/comments/ideas/suggestions/whatever are most welcome!

Thanks and best regards,
-- 
Didi
___
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/OCK5XKCFLTBIE6HQWCF4R7FMR3IYQTXW/

[ovirt-devel] Re: [ACTION REQUIRED] engine-setup: getCredentials updated

[Yedidyah Bar David]

On Thu, Aug 25, 2022 at 11:17 AM Yedidyah Bar David  wrote:
>
> On Thu, Aug 25, 2022 at 11:14 AM Yedidyah Bar David  wrote:
> >
> > On Wed, Aug 24, 2022 at 4:02 PM Yedidyah Bar David  wrote:
> > >
> > > Hi all,
> > >
> > > We now merged all of these patches:
> > >
> > > [1] https://github.com/oVirt/otopi/pull/29
> > > [2] https://github.com/oVirt/ovirt-engine/pull/585
> > > [3] https://github.com/oVirt/ovirt-engine-keycloak/pull/53
> > > [4] https://github.com/oVirt/ovirt-dwh/pull/47
> > >
> > > If you have a new dwh and/or keycloak, and an older engine, and run
> > > engine-setup, and get an error about getCredentials, please update
> > > both otopi and the engine.
> >
> > Also: If you run engine-setup and it outputs nothing, you should update 
> > otopi.
> >
> > There was a bug in the copr build of otopi, that the release wasn't
> > changed between builds. So the updated otopi didn't get a new release.
> > I fixed it this morning. So please update otopi. Sorry for the mess...
>
> And if you do not get an update, try first 'sudo clean all'.

sudo dnf clean all

/me wonders how many more messages on this thread would be needed

> The correct version
> is:
>
> python3-otopi-1.10.3-0.0.master.20220825055305.git7e9995c.el8.noarch
> otopi-common-1.10.3-0.0.master.20220825055305.git7e9995c.el8.noarch
>
> Best regards,
> --
> Didi



-- 
Didi
___
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/NTVAA5FQPBHAKIML2DIGD5BN5SRGFNPO/

[ovirt-devel] Re: [ACTION REQUIRED] engine-setup: getCredentials updated

[Yedidyah Bar David]

On Thu, Aug 25, 2022 at 11:14 AM Yedidyah Bar David  wrote:
>
> On Wed, Aug 24, 2022 at 4:02 PM Yedidyah Bar David  wrote:
> >
> > Hi all,
> >
> > We now merged all of these patches:
> >
> > [1] https://github.com/oVirt/otopi/pull/29
> > [2] https://github.com/oVirt/ovirt-engine/pull/585
> > [3] https://github.com/oVirt/ovirt-engine-keycloak/pull/53
> > [4] https://github.com/oVirt/ovirt-dwh/pull/47
> >
> > If you have a new dwh and/or keycloak, and an older engine, and run
> > engine-setup, and get an error about getCredentials, please update
> > both otopi and the engine.
>
> Also: If you run engine-setup and it outputs nothing, you should update otopi.
>
> There was a bug in the copr build of otopi, that the release wasn't
> changed between builds. So the updated otopi didn't get a new release.
> I fixed it this morning. So please update otopi. Sorry for the mess...

And if you do not get an update, try first 'sudo clean all'. The correct version
is:

python3-otopi-1.10.3-0.0.master.20220825055305.git7e9995c.el8.noarch
otopi-common-1.10.3-0.0.master.20220825055305.git7e9995c.el8.noarch

Best regards,
-- 
Didi
___
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/5XOVKE4ZLA3XCMUA2W7J7WDXDF4KN4JU/

[ovirt-devel] Re: [ACTION REQUIRED] engine-setup: getCredentials updated

[Yedidyah Bar David]

On Wed, Aug 24, 2022 at 4:02 PM Yedidyah Bar David  wrote:
>
> Hi all,
>
> We now merged all of these patches:
>
> [1] https://github.com/oVirt/otopi/pull/29
> [2] https://github.com/oVirt/ovirt-engine/pull/585
> [3] https://github.com/oVirt/ovirt-engine-keycloak/pull/53
> [4] https://github.com/oVirt/ovirt-dwh/pull/47
>
> If you have a new dwh and/or keycloak, and an older engine, and run
> engine-setup, and get an error about getCredentials, please update
> both otopi and the engine.

Also: If you run engine-setup and it outputs nothing, you should update otopi.

There was a bug in the copr build of otopi, that the release wasn't
changed between builds. So the updated otopi didn't get a new release.
I fixed it this morning. So please update otopi. Sorry for the mess...

BTW: You can also run 'OTOPI_DEBUG=1 engine-setup' and get an error message.

Best regards,
-- 
Didi
___
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/KX3W7A7A4YUGYXSH4UW6NK5LLOEEKOCR/

[ovirt-devel] [ACTION REQUIRED] engine-setup: getCredentials updated

[Yedidyah Bar David]

Hi all,

We now merged all of these patches:

[1] https://github.com/oVirt/otopi/pull/29
[2] https://github.com/oVirt/ovirt-engine/pull/585
[3] https://github.com/oVirt/ovirt-engine-keycloak/pull/53
[4] https://github.com/oVirt/ovirt-dwh/pull/47

If you have a new dwh and/or keycloak, and an older engine, and run
engine-setup, and get an error about getCredentials, please update
both otopi and the engine.

Thanks and best regards,
-- 
Didi
___
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/NFGVORKPTIMMV67D4FKFSXNNFHAMCEUH/

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

[Yedidyah Bar David]

On Tue, Aug 16, 2022 at 11:30 AM Michal Skrivanek 
wrote:

>
>
> On 11. 8. 2022, at 8:24, Yedidyah Bar David  wrote:
>
> On Thu, Jul 21, 2022 at 5:04 PM Scott Dickerson 
> wrote:
>
>
>
>
> On Thu, Jul 21, 2022 at 9:35 AM Michal Skrivanek 
> wrote:
>
>
>
>
> On 21. 7. 2022, at 9:09, Yedidyah Bar David  wrote:
>
> On Fri, Jul 8, 2022 at 11:30 AM Martin Perina  wrote:
>
>
>
>
> On Fri, Jul 8, 2022 at 10:27 AM Michal Skrivanek 
> wrote:
>
>
>
>
> On 7. 7. 2022, at 19:28, Nir Soffer  wrote:
>
> 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).
>
>
> merge commits are disabled for all oVirt projects as per
> https://www.ovirt.org/develop/developer-guide/migrating_to_github.html
>
>
> It should be easy to change, using [2]:
>
> - uses: actions/checkout@v2
> with:
>   ref: ${{ github.event.pull_request.head.sha }}
>
>
> we can really just create a trivial wrapper and replace globally with e.g.
> - uses: ovirt/checkout
>
>
>
> +1
>
> As this needs to be included in each project separately, then I'd say
> let's minimize available options to ensure maximum consistency across all
> oVirt projects
>
>
>
> 1. I don't know how, and would have to learn quite a bit of github, to do
> this. That's the main reason I neglected this in my TODO folder and didn't
> reply yet. Perhaps someone already did something similar and would like to
> take over?
>
>
> Take a look at https://github.com/oVirt/upload-rpms-action
> minus tests (I hope Janos is not looking)...that makes it a new repo, and
> license, readme, and yaml file with that snippet. that's it.
>
>
> I am hesitant about the value of this exercise, but with Martin's
> encouragement decided to try, and it seems to work indeed:
>
> https://github.com/didib/checkout-head-sha
> https://github.com/didib/test-checkout/pull/2
>
> Check the output of 'git log' in the check - it shows the PR hash.
>
> So please create a repo (e.g. oVirt/checkout or whatever) and I'll
> push a PR there.
>
>
> https://github.com/oVirt/checkout-action
> you have Write permissions there
>

Pushed and merged a single PR [1], updated my test repo to use it [2],
tested it [3], seems ok.

[1] https://github.com/oVirt/checkout-action/pull/1
[2]
https://github.com/didib/test-checkout/commit/6d188ae88b8a58bde16d6a537123be9b90c14e0b
[3] https://github.com/didib/test-checkout/pull/3


>
>
> Didn't add test code :-).
>
>
>
> 2. I already pushed (2 weeks ago) and merged (yesterday) to otopi, [1],
> which simply does the above.
>
> 3. Scott now pushed [2], to the engin

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

[Yedidyah Bar David]

On Thu, Jul 21, 2022 at 5:04 PM Scott Dickerson  wrote:
>
>
>
> On Thu, Jul 21, 2022 at 9:35 AM Michal Skrivanek  wrote:
>>
>>
>>
>> On 21. 7. 2022, at 9:09, Yedidyah Bar David  wrote:
>>
>> On Fri, Jul 8, 2022 at 11:30 AM Martin Perina  wrote:
>>>
>>>
>>>
>>> On Fri, Jul 8, 2022 at 10:27 AM Michal Skrivanek  
>>> wrote:
>>>>
>>>>
>>>>
>>>> > On 7. 7. 2022, at 19:28, Nir Soffer  wrote:
>>>> >
>>>> > 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).
>>>>
>>>> merge commits are disabled for all oVirt projects as per 
>>>> https://www.ovirt.org/develop/developer-guide/migrating_to_github.html
>>>>
>>>> >
>>>> >> It should be easy to change, using [2]:
>>>> >>
>>>> >> - uses: actions/checkout@v2
>>>> >>  with:
>>>> >>ref: ${{ github.event.pull_request.head.sha }}
>>>>
>>>> we can really just create a trivial wrapper and replace globally with e.g.
>>>> - uses: ovirt/checkout
>>>
>>>
>>> +1
>>>
>>> As this needs to be included in each project separately, then I'd say let's 
>>> minimize available options to ensure maximum consistency across all oVirt 
>>> projects
>>
>>
>> 1. I don't know how, and would have to learn quite a bit of github, to do 
>> this. That's the main reason I neglected this in my TODO folder and didn't 
>> reply yet. Perhaps someone already did something similar and would like to 
>> take over?
>>
>>
>> Take a look at https://github.c

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

[Yedidyah Bar David]

On Fri, Jul 8, 2022 at 11:30 AM Martin Perina  wrote:

>
>
> On Fri, Jul 8, 2022 at 10:27 AM Michal Skrivanek 
> wrote:
>
>>
>>
>> > On 7. 7. 2022, at 19:28, Nir Soffer  wrote:
>> >
>> > 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).
>>
>> merge commits are disabled for all oVirt projects as per
>> https://www.ovirt.org/develop/developer-guide/migrating_to_github.html
>>
>> >
>> >> It should be easy to change, using [2]:
>> >>
>> >> - uses: actions/checkout@v2
>> >>  with:
>> >>ref: ${{ github.event.pull_request.head.sha }}
>>
>> we can really just create a trivial wrapper and replace globally with e.g.
>> - uses: ovirt/checkout
>>
>
> +1
>
> As this needs to be included in each project separately, then I'd say
> let's minimize available options to ensure maximum consistency across all
> oVirt projects
>

1. I don't know how, and would have to learn quite a bit of github, to do
this. That's the main reason I neglected this in my TODO folder and didn't
reply yet. Perhaps someone already did something similar and would like to
take over?

2. I already pushed (2 weeks ago) and merged (yesterday) to otopi, [1],
which simply does the above.

3. Scott now pushed [2], to the engine, doing the same, and I agree with
him. So am going to merge it soon, unless there are objections. If
eventually someone creates an oVirt action for this, we can always update
to use it.

Best regards,

[1] https://github.com/oVirt/otopi/pull/25

[2] https://github.com/oVirt/ovirt-engine/pull/543


>
>> >
>> > +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/WZ3W6BII34CTQXXLBYJB6W6ECCWE

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

[Yedidyah Bar David]

On Thu, Jul 7, 2022 at 1:31 PM Strahil Nikolov  wrote:
>
> Erm ... does this mean that based on rpm, we can easily find the commit ?

Exactly.

Please note that this is a devel list, and we discuss dev builds...
Release builds should always have nice and clean version numbers
always pointing at relevant git tags.

Best regards,

>
> Best Regards,
> Strahil Nikolov
>
> On Thu, Jul 7, 2022 at 11:36, Yedidyah Bar David
>  wrote:
> 3 weeks later, no-one other than Michal replied...
>
> Adding a few more people trying to get their attention.
>
> On Thu, Jun 16, 2022 at 3:31 PM Yedidyah Bar David  wrote:
> >
> > On Thu, Jun 16, 2022 at 1:27 PM Yedidyah Bar David  wrote:
> > >
> > > On Wed, Jun 15, 2022 at 8:31 PM Michal Skrivanek  
> > > wrote:
> > > >
> > > >
> > > >
> > > > > On 15. 6. 2022, at 11:25, 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?
> > > >
> > > > huh, I wondered about that same thing today
> > > > Thank you for explaining why I couldn't find that hash anywhere
> > > >
> > > > > 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).
> > > >
> > > > We should create ovirt-github-ra...@ovirt.org, I'd certainly 
> > > > contribute:-) It's amazing how horrible _and_ popular github is.
> > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > 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?
> > > > >
> > > > > It should be easy to change, using [2]:
> > > > >
> > > > > - uses: actions/checkout@v2
> > > > >  with:
> > > > >ref: ${{ github.event.pull_request.head.sha }}
> > > > >
> > > > > No need to reach a complete consensus - can be decided upon
> > > > > per-project/repo.
> > > >
> > > > github is always quite horrible to maintain some consistency across 
> > > > projects...yeah, I'd really like to have the same approach for every 
> > > > single project, it simplifies the maintenacewe do have a lot of 
> > > > projects and many are not very active and they easily fall behind. 
> > > > After all we have 160 projects in oVirt org but only ~30 are 
> > > > activeor rather 30 are in use for oVirt compose and ~10 are active.
> > > >
> > >

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

[Yedidyah Bar David]

3 weeks later, no-one other than Michal replied...

Adding a few more people trying to get their attention.

On Thu, Jun 16, 2022 at 3:31 PM Yedidyah Bar David  wrote:
>
> On Thu, Jun 16, 2022 at 1:27 PM Yedidyah Bar David  wrote:
> >
> > On Wed, Jun 15, 2022 at 8:31 PM Michal Skrivanek  
> > wrote:
> > >
> > >
> > >
> > > > On 15. 6. 2022, at 11:25, 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?
> > >
> > > huh, I wondered about that same thing today
> > > Thank you for explaining why I couldn't find that hash anywhere
> > >
> > > > 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).
> > >
> > > We should create ovirt-github-ra...@ovirt.org, I'd certainly 
> > > contribute:-) It's amazing how horrible _and_ popular github is.
> > >
> > > >
> > > > 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.
> > > >
> > > > 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?
> > > >
> > > > It should be easy to change, using [2]:
> > > >
> > > > - uses: actions/checkout@v2
> > > >  with:
> > > >ref: ${{ github.event.pull_request.head.sha }}
> > > >
> > > > No need to reach a complete consensus - can be decided upon
> > > > per-project/repo.
> > >
> > > github is always quite horrible to maintain some consistency across 
> > > projects...yeah, I'd really like to have the same approach for every 
> > > single project, it simplifies the maintenacewe do have a lot of 
> > > projects and many are not very active and they easily fall behind. After 
> > > all we have 160 projects in oVirt org but only ~30 are activeor 
> > > rather 30 are in use for oVirt compose and ~10 are active.
> > >
> > > +1 on using it everywhere
> > > we have our own action for rpms and buildcontainer for unified build 
> > > environment (with a shameful exception of vdsm!)it's probably 
> > > overkill for checkout to use oVirt's action

Yes, that's my own preference as well. I am going to push patches to a few
projects doing this, perhaps including ones I am not very active in. Feel
free to ignore/disagree and I'll close.

> > >
> > > > But if you disagree, I'd like to understand why.
> >
> > If someone _wants_ the current behavior (merge to HEAD) but is just
> > annoyed by the commit hash, an alternative is to use the PR hash in
> > the name. Now tried this POC, seems to work:
> >
> > https://github.com/oVirt/otopi/pull/23
>
> Also this one. Much simpler, but perhaps we still want the refactoring of ^^.
>
> https://github.com/oVirt/otopi/pull/24

(Going to close both of the above)

Best regards,
-- 
Didi
___
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/JKI57UOHTMQE3GWBAYQHZ4LTZ5PKLLI3/

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

[Yedidyah Bar David]

On Thu, Jun 16, 2022 at 1:27 PM Yedidyah Bar David  wrote:
>
> On Wed, Jun 15, 2022 at 8:31 PM Michal Skrivanek  wrote:
> >
> >
> >
> > > On 15. 6. 2022, at 11:25, 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?
> >
> > huh, I wondered about that same thing today
> > Thank you for explaining why I couldn't find that hash anywhere
> >
> > > 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).
> >
> > We should create ovirt-github-ra...@ovirt.org, I'd certainly contribute:-) 
> > It's amazing how horrible _and_ popular github is.
> >
> > >
> > > 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.
> > >
> > > 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?
> > >
> > > It should be easy to change, using [2]:
> > >
> > > - uses: actions/checkout@v2
> > >  with:
> > >ref: ${{ github.event.pull_request.head.sha }}
> > >
> > > No need to reach a complete consensus - can be decided upon
> > > per-project/repo.
> >
> > github is always quite horrible to maintain some consistency across 
> > projects...yeah, I'd really like to have the same approach for every single 
> > project, it simplifies the maintenacewe do have a lot of projects and 
> > many are not very active and they easily fall behind. After all we have 160 
> > projects in oVirt org but only ~30 are activeor rather 30 are in use 
> > for oVirt compose and ~10 are active.
> >
> > +1 on using it everywhere
> > we have our own action for rpms and buildcontainer for unified build 
> > environment (with a shameful exception of vdsm!)it's probably overkill 
> > for checkout to use oVirt's action
> >
> > > But if you disagree, I'd like to understand why.
>
> If someone _wants_ the current behavior (merge to HEAD) but is just
> annoyed by the commit hash, an alternative is to use the PR hash in
> the name. Now tried this POC, seems to work:
>
> https://github.com/oVirt/otopi/pull/23

Also this one. Much simpler, but perhaps we still want the refactoring of ^^.

https://github.com/oVirt/otopi/pull/24

>
> Best regards,
>
> > > Thanks.
> > >
> > > Best regards,
> > >
> > > [1] https://github.com/oVirt/vdsm/runs/6881311961?check_suite_focus=true
> > >
> > > [2] 
> > > https://github.com/marketplace/actions/checkout?version=v2.4.2#checkout-pull-request-head-commit-instead-of-merge-commit
> > >
> > > [3] https://github.com/oVirt/vdsm/pull/249
> > > --
> > > Didi
> > > ___
> > > 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/7SEFKOASOATTMO2NK2SBWMOV4CV6LZOS/
> >
>
>
> --
> Didi



-- 
Didi
___
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/GZP4XZNYYEO2H263WCD4B3DAQHFOJUUC/

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

[Yedidyah Bar David]

On Wed, Jun 15, 2022 at 8:31 PM Michal Skrivanek  wrote:
>
>
>
> > On 15. 6. 2022, at 11:25, 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?
>
> huh, I wondered about that same thing today
> Thank you for explaining why I couldn't find that hash anywhere
>
> > 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).
>
> We should create ovirt-github-ra...@ovirt.org, I'd certainly contribute:-) 
> It's amazing how horrible _and_ popular github is.
>
> >
> > 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.
> >
> > 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?
> >
> > It should be easy to change, using [2]:
> >
> > - uses: actions/checkout@v2
> >  with:
> >ref: ${{ github.event.pull_request.head.sha }}
> >
> > No need to reach a complete consensus - can be decided upon
> > per-project/repo.
>
> github is always quite horrible to maintain some consistency across 
> projects...yeah, I'd really like to have the same approach for every single 
> project, it simplifies the maintenacewe do have a lot of projects and 
> many are not very active and they easily fall behind. After all we have 160 
> projects in oVirt org but only ~30 are activeor rather 30 are in use for 
> oVirt compose and ~10 are active.
>
> +1 on using it everywhere
> we have our own action for rpms and buildcontainer for unified build 
> environment (with a shameful exception of vdsm!)it's probably overkill 
> for checkout to use oVirt's action
>
> > But if you disagree, I'd like to understand why.

If someone _wants_ the current behavior (merge to HEAD) but is just
annoyed by the commit hash, an alternative is to use the PR hash in
the name. Now tried this POC, seems to work:

https://github.com/oVirt/otopi/pull/23

Best regards,

> > Thanks.
> >
> > Best regards,
> >
> > [1] https://github.com/oVirt/vdsm/runs/6881311961?check_suite_focus=true
> >
> > [2] 
> > https://github.com/marketplace/actions/checkout?version=v2.4.2#checkout-pull-request-head-commit-instead-of-merge-commit
> >
> > [3] https://github.com/oVirt/vdsm/pull/249
> > --
> > Didi
> > ___
> > 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/7SEFKOASOATTMO2NK2SBWMOV4CV6LZOS/
>


-- 
Didi
___
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/4QKHC4WEFYPBRD4VHQKHLKVW3QK2EOFU/

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

[Yedidyah Bar David]

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.

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?

It should be easy to change, using [2]:

- uses: actions/checkout@v2
  with:
ref: ${{ github.event.pull_request.head.sha }}

No need to reach a complete consensus - can be decided upon
per-project/repo. But if you disagree, I'd like to understand why.
Thanks.

Best regards,

[1] https://github.com/oVirt/vdsm/runs/6881311961?check_suite_focus=true

[2] 
https://github.com/marketplace/actions/checkout?version=v2.4.2#checkout-pull-request-head-commit-instead-of-merge-commit

[3] https://github.com/oVirt/vdsm/pull/249
-- 
Didi
___
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/7SEFKOASOATTMO2NK2SBWMOV4CV6LZOS/

[ovirt-devel] Re: oVirt website switching to 'main' branch

[Yedidyah Bar David]

On Thu, Jun 9, 2022 at 1:34 PM Marc Dequènes (Duck)  wrote:
>
> Quack,
>
> Following Red Hat conscious language initiative we're switching the
> development branch to 'main' on the ovirt-site repository.
>
> This will happen on 2022-06-20 around 10:30-11:30 Japan time.
>
> If you encounter any problem after this date please contact me by mail
> or chat (duck on IRC).

Good luck!

Not sure what the exact plan is, but IMO you should just remove
'master' completely. At most, perhaps rename it to something like
'Master_branch_not_used_use_main_instead' or something like that. If
you just remove, or use a capital 'M', then tab-completion like e.g.
`git command remote/ma` will work just as well as today...

Do you have recipes you used for other projects as well?

And, are there plans to do something similar for other oVirt git repos?

Best regards,
-- 
Didi
___
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/ZU2X3V2H4I6Y2W7GT33YAJ7HJBETTMCU/

[ovirt-devel] Re: [ovirt-users] Re: [IMPORTANT] Upgrade to postgresql-jdbc-42.2.14-1 breaks oVirt Engine 4.4/4.5

[Yedidyah Bar David]

On Wed, May 11, 2022 at 10:18 PM Martin Perina  wrote:
>
> Hi,
>
> as mentioned in 4.5.0.8 announcement and Doc Text of 
> https://bugzilla.redhat.com/show_bug.cgi?id=2077794 postgresql-jdbc >= 
> 42.2.14 is required for ovirt-engine to work properly.
>
> So please remove the exclude, update postgresql-jdbc to the latest and 
> restart ovirt-engine service.

Perhaps we should have updated the spec file to Require: the correct version.

This would have caused engine-setup (upgrade), if the new version was
excluded/blocked/whatever, to fail - rather early and safely, IMO.

Best regards,

>
> Martin
>
> On Wed, May 11, 2022 at 4:52 PM Maton, Brett  wrote:
>>
>> Probably worth pointing out that if you (as I did) update to 4.5.0.8 and 
>> exclude the postgresql-jdbc update you'll wind up with
>>
>> 500 - Internal Server Error
>>
>> When you try to login to the admin console again.
>>
>> On Wed, 11 May 2022 at 13:43, Martin Perina  wrote:
>>>
>>> Hi,
>>>
>>> oVirt 4.5.0.8 async release has fixed the issue with postgresql-jdbc 
>>> drivers:
>>>
>>> https://lists.ovirt.org/archives/list/us...@ovirt.org/thread/GAENJ2DPZSDCC276KM5QKUAZE5XPWTRG/
>>>
>>> So for oVirt 4.5.0.8 you no longer need to exclude postgresql-jdbc >= 
>>> 42.2.14 package during installation/upgrade.
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>> On Fri, Apr 22, 2022 at 5:35 PM Martin Perina  wrote:

 Hi,
 Unfortunately we have just found that latest release of 
 postgresql-jdbc-42.2.14-1 breaks existing oVirt Engine 4.4 and 4.5 
 installations running on CentOS Stream.
 The workaround is to downgrade to previous version, for example 
 postgresql-jdbc-42.2.3-3 should work fine.

 Here are detailed instructions:

 1. If you have already upgraded to postgresql-jdbc-42.2.14-1, please 
 downgrade to previous version:

 $ dnf downgrade postgresql-jdbc
 $ systemctl restart ovirt-engine

 2. If you are going to upgrade your oVirt Engine machine, please exclude 
 postgresql-jdbc package from upgrades:

 $ dnf update -x postgresql-jdbc

 We have created https://bugzilla.redhat.com/2077794 to track this issue, 
 but unfortunately we don't have a fix yet.

 Regards,
 Martin

 --
 Martin Perina
 Manager, Software Engineering
 Red Hat Czech s.r.o.
>>>
>>>
>>>
>>> --
>>> Martin Perina
>>> Manager, Software Engineering
>>> Red Hat Czech s.r.o.
>>> ___
>>> Users mailing list -- us...@ovirt.org
>>> To unsubscribe send an email to users-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/us...@ovirt.org/message/GVFSXYLTQKRAVAVXY5ONBN4NRI24ED55/
>
>
>
> --
> Martin Perina
> Manager, Software Engineering
> Red Hat Czech s.r.o.
> ___
> Users mailing list -- us...@ovirt.org
> To unsubscribe send an email to users-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/us...@ovirt.org/message/DKWQJMDQVQRLKYPQTBIPVJM4WZHY2FAY/



-- 
Didi
___
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/HSABWV3ITXP53NQGANBZTQQGYMNGSDJP/

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

[Yedidyah Bar David]

On Thu, Mar 31, 2022 at 12:10 AM JC Lopez  wrote:

> See inline
>
> On Mar 30, 2022, at 13:41, Nir Soffer  wrote:
>
> 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?
>
>
Sorry, I do not have the full picture. Anyway:

1. Right now, the engine still requires ansible-2.9 [1].

2. The hosts - el8stream (or ovirt-node) - require (or include)
ansible-core-2.12.

So if you run into conflicts/requirements issues, please clarify
exactly what you do and on which machine (engine or host).

This is all changing quickly and has changed in the last few days.
I hope [1] will be merged by the time of beta, not sure.

If you want to test the very current state, I recommend to run a
full 'dnf update' or 'dnf update --nobest' (and note what wasn't
upgraded), perhaps after doing 'dnf update \*release\*'.

On my own machines, I have both virt-install and ansible-core from
repo "appstream" (meaning CentOS, not oVirt).

[1] https://github.com/oVirt/ovirt-engine/pull/199


>
> Here is what I have configured on my single node if it can help
> [root@client2 ~]# dnf repolist
>

I quickly skimmed through the list below and did not notice anything
obviously wrong.

Good luck and best regards,


> Repository copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot is
> listed more than once in the configuration
> repo id
> repo
> name
> appstream
> CentOS
> Stream 8 - AppStream
> baseos
>CentOS
> Stream 8 - BaseOS
> copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
>  Copr
> repo for ovirt-master-snapshot owned by ovirt
> elrepo
>
> ELRepo.org Community Enterprise Linux Repository - el8
> epel
>Extra
> Packages for Enterprise Linux 8 - x86_64
> epel-modular
>Extra
> Packages for Enterprise Linux Modular 8 - x86_64
> extras
>CentOS
> Stream 8 - Extras
> extras-common
> CentOS
> Stream 8 - Extras common packages
> ovirt-appliance-master-snapshot
> oVirt
> appliance with ovirt-master-snapshot content
> ovirt-master-centos-opstools-testing
>CentOS
> Stream 8 - OpsTools - collectd
> ovirt-master-centos-stream-ceph-pacific
> CentOS
> Stream 8 - Ceph packages for x86_64
> ovirt-master-centos-stream-gluster10-testing
>CentOS
> Stream 8 - Glusterfs 10 - testing
> ovirt-master-centos-stream-nfv-openvswitch2-testing
> CentOS
> Stream 8 - NFV OpenVSwitch 2 - testing
> ovirt-master-centos-stream-openstack-yoga-testing
> CentOS
> Stream 8 - OpenStack Yoga Repository - testing
> ovirt-master-centos-stream-ovirt45-testing
>CentOS
> Stream 8 - oVirt 4.5 - testing
> ovirt-master-copr:copr.fedorainfracloud.org:sac:gluster-ansible
> Copr
> repo for gluster-ansible owned by sac
> ovirt-master-epel
> Extra
> Packages for Enterprise Linux 8 - x86_64
> ovirt-master-virtio-win-latest
>
>  virtio-win builds roughly matching what will be shipped in upcoming RHEL
> ovirt-node-master-snapshot
>oVirt
> Node with ovirt-master-snapshot content
> powertools
>CentOS
> Stream 8 - PowerTools
> rdo-delorean-component-cinder
> RDO
> Delorean OpenStack Cinder - current
> rdo-delorean-component-clients
>   

[ovirt-devel] github commit hashes at CI/before merge/after merge

[Yedidyah Bar David]

Hi all,

Now spent a few minutes verifying that OST indeed failed [1] on the
results of [2] and not on something else. The generated rpm's name is
ovirt-hosted-engine-setup-2.6.2-0.0.master.20220322151459.git8af2a1f.el8.noarch.rpm
, where 8af2a1f is a result of [4]:

```
/usr/bin/git checkout --progress --force refs/remotes/pull/33/merge
Note: switching to 'refs/remotes/pull/33/merge'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c 
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 8af2a1f Merge 1dcab4385f4e4b9e40feac9d2e00e78d8dde3df4
into b1e3bd386dcf781f62bde4d58ea26f93649c8f93
```

You have to press "Run actions/checkout@v2" and then "Checking out the
ref", to see this, or the "Ship wheel" icon and then "View raw logs".
I prefer the latter, but the link it generates is temporary and
already expired, so not pasting it here.

1dcab4385f4e4b9e40feac9d2e00e78d8dde3df4 is the commit of [2] and
b1e3bd386dcf781f62bde4d58ea26f93649c8f93 is current HEAD (master). It
seems like I can force it to not merge using [3] - didn't try - but
not sure it makes that much more sense either. *Perhaps* 8af2a1f is
the commit that would eventually enter the git log, and so it would
then make sense to be able to match the CI results [1]. I think I
still prefer not having to go through all of this - instead, have a
"merge strategy" of "just move the HEAD to this commit and that's it",
AKA "fast-forward" AFAIK, but as discussed internally a few months
ago, I do not think there is a nice way to achieve this, other than
force pushing directly to master from remote - I failed to find a way
to do this in the web UI (and to make force pushing clarified in the
UI either).

Comments/opinions, anyone?

Do we want [3]?

Does anyone care at all, other than me?

Best regards,

[1] 
https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ds-ost-baremetal_manual/31488/
[2] https://github.com/oVirt/ovirt-hosted-engine-setup/actions/runs/2023236328
[3] 
https://github.com/actions/checkout#Checkout-pull-request-HEAD-commit-instead-of-merge-commit
[4] 
https://github.com/oVirt/ovirt-hosted-engine-setup/runs/5646552158?check_suite_focus=true
-- 
Didi
___
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/NYU4UVSQRBMID7CARTUFUEXSVW3TBII4/

[ovirt-devel] Re: The connection between the Engine and the hosts has been broken. On the Engine side, all hosts are in the "NonResponsive" state, and on the hosts "ERROR ssl handshake".

[Yedidyah Bar David]

On Tue, Mar 22, 2022 at 8:49 AM  wrote:
>
> The connection between the Engine and the hosts has been broken. On the 
> Engine side, all hosts are in the "NonResponsive" state, and on the hosts 
> "ERROR ssl handshake".
> oVirt 4.4.4.7-1.el8

Perhaps your certificates expired? Please see other recent threads
here about this and about how to renew/enroll them. Thanks.

Best regards,
-- 
Didi
___
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/TTYOGZTPMUYHG6QP3K4ZN7HD2VLEDB33/

[ovirt-devel] Re: Alpha 4.5 Test Day | Deploy on Ceph Storage

[Yedidyah Bar David]

On Thu, Mar 17, 2022 at 1:35 PM Jöran Malek  wrote:
>
> Performed a dnf list for python3-sqlalchemy:
> dnf --showduplicates list python3-sqlalchemy
> Last metadata expiration check: 2:25:41 ago on Thu 17 Mar 2022 09:21:55 AM 
> CET.
> Installed Packages
> python3-sqlalchemy.x86_64  1.4.18-1.1.el8
>  @centos-openstack-xena
> Available Packages
> python3-sqlalchemy.x86_64
> 1.3.2-2.module_el8.5.0+751+b79b40be  appstream
> python3-sqlalchemy.x86_64
> 1.3.2-2.module_el8.5.0+761+faacb0fb  appstream
> python3-sqlalchemy.x86_64  1.4.18-1.1.el8
>  centos-openstack-xena
>
> Installed is the latest version from centos-openstack-xena.
>
> Repositories enabled/available:
> # dnf repolist
> repo id  repo name
> appstreamCentOS Stream 8 - AppStream
> baseos   CentOS Stream 8 - BaseOS
> centos-advanced-virtualization   CentOS-8 - Advanced
> Virtualization
> centos-ceph-pacific  CentOS-8-stream - Ceph 
> Pacific
> centos-nfv-openvswitch   CentOS-8 - NFV OpenvSwitch
> centos-openstack-xenaCentOS-8 - OpenStack xena
> centos-opstools  CentOS-OpsTools - collectd
> centos-ovirt45   CentOS Stream 8 - oVirt 4.5
> centos-ovirt45-testing   CentOS Stream 8 -
> oVirt 4.5 - Testing
> centos-rabbitmq-38   CentOS-8 - RabbitMQ 38
> extras   CentOS Stream 8 - Extras
> ovirt-45-centos-stream-gluster10 CentOS Stream 8 -
> oVirt 4.5 - Glusterfs 10
> ovirt-45-centos-stream-openstack-yoga-testingCentOS Stream 8 -
> oVirt 4.5 - OpenStack Yoga Repository - testing

Can you check if above one is enabled and does not filter anything
other than ansible? On my machine I have:

Last metadata expiration check: 3:42:39 ago on Thu 17 Mar 2022 09:59:49 AM IST.
Installed Packages
python3-sqlalchemy.x86_64 1.4.31-1.el8
@ovirt-master-centos-stream-openstack-yoga-testing
Available Packages
python3-sqlalchemy.x86_64 1.3.2-2.module_el8.5.0+751+b79b40be
appstream
python3-sqlalchemy.x86_64 1.3.2-2.module_el8.5.0+761+faacb0fb
appstream
python3-sqlalchemy.x86_64 1.4.18-1.1.el8
ovirt-master-centos-stream-openstack-yoga-testing
python3-sqlalchemy.x86_64 1.4.31-1.el8
ovirt-master-centos-stream-openstack-yoga-testing

Perhaps 'dnf clean all', 'dnf reinstall \*release\*', etc.?

> ovirt-45-upstreamoVirt upstream for
> CentOS Stream 8 - oVirt 4.5
> ovirt-45-upstream-testingoVirt upstream for
> CentOS Stream 8 - oVirt 4.5 - testing
> powertools   CentOS Stream 8 - PowerTools
>
> As far as I can tell the latest sqlalchemy-version is installed.
>
> With 1.3.2 installed this is what I get instead:
> 2022-03-17 12:11:09,562 - cinderlib-client - ERROR - Failure occurred
> when trying to run command 'storage_stats': 'int' object is not
> iterable [3a9e3104-ca4b-40bd-bb92-7822a3f6698d]
> 2022-03-17 12:12:17,252 - cinderlib-client - ERROR - Failure occurred
> when trying to run command 'storage_stats': 'int' object is not
> iterable [c6a6c72a-0031-4a2f-80d5-a325e81802d3]
> ___
> 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/7VUVROP5TEFP7QVOGSCQ2EQRIBPXX2F3/



-- 
Didi
___
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/DJL6WKJQJQDQPVMUTQDSWWBBWVGHNGMV/

[ovirt-devel] Re: engine-setup failed on absent external_truststore

[Yedidyah Bar David]

On Tue, Feb 15, 2022 at 3:38 AM Shmuel Melamud  wrote:
>
> Hi!
>
> Unfortunately, I couldn't find any explanation in the log. The log is 
> attached.

Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/otopi/context.py", line
engine32, in _executeMethod
method['method']()
  File 
"/home/smelamud/engine-root/master/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py",
line engine048, in _misc_configure_provider
self._upate_external_providers_keystore()
  File 
"/home/smelamud/engine-root/master/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py",
line 832, in _upate_external_providers_keystore
stat.S_IRUSR | stat.S_IWUSR | stat.S_IRGRP | stat.S_IROTH,
  File 
"/home/smelamud/engine-root/master/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py",
line 582, in _set_file_permissions
file_path
FileNotFoundError: [Errno 2] No such file or directory:
'/home/smelamud/engine-root/master/var/lib/ovirt-engine/external_truststore'

Most recent relevant change was done by Eitan, "setup ovn: set
truststore file permissions". Eitan - do you remember if you checked
it on a dev env? Thanks.

Best regards,
-- 
Didi
___
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/76EX3YOFCX5P6LXHW3VISLXV7MKCQG4V/

[ovirt-devel] Re: engine-setup failed on absent external_truststore

[Yedidyah Bar David]

On Sun, Feb 13, 2022 at 5:16 AM Shmuel Melamud  wrote:
>
> Hi!
>
> Tried to reinstall the current master in a clean directory.
> engine-setup failed with the following error:
>
> [ INFO  ] Stage: Misc configuration
> [ INFO  ] Upgrading CA
> [ INFO  ] Creating CA:
> /home/smelamud/engine-root/master/etc/pki/ovirt-engine/ca.pem
> [ INFO  ] Creating CA:
> /home/smelamud/engine-root/master/etc/pki/ovirt-engine/qemu-ca.pem
> [ INFO  ] Updating OVN SSL configuration
> [ INFO  ] Updating OVN timeout configuration
> [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 2] No
> such file or directory:
> '/home/smelamud/engine-root/master/var/lib/ovirt-engine/external_truststore'
>
> How can this be solved?

Please check/share the setup log. Thanks.

Best regards,
-- 
Didi
___
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/K4MBQMEPVQHFIUI45D3LE5CTMWYIT3UZ/

[ovirt-devel] Re: [ovirt-users] Re: oVirt 4.4.10 Async update #2

[Yedidyah Bar David]

On Sat, Jan 29, 2022 at 11:56 AM David White via Users 
wrote:

> Is it safe to remove this package as well?
> I noticed the following during the execution of engine-setup:
>
> [ INFO  ] DNF Unknown:
> ovirt-engine-extension-logger-log4j-1.1.1-1.el8.noarch
>

Should be, see also: https://bugzilla.redhat.com/2044277 .

Best regards,


>
> Sent with ProtonMail  Secure Email.
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, January 26th, 2022 at 9:20 AM, Sandro Bonazzola <
> sbona...@redhat.com> wrote:
>
> On January 26th 2022 the oVirt project released an async update to the
> following packages:
>
> - ovirt-engine 4.4.10.6
>
> Fixing the following bugs:
> - [BZ 2044277 ] -
> Replace ovirt-engine-extension-logger-log4j with internal ovirt-engine
> implementation
> Package ovirt-engine-extension-logger-log4j has been obsoleted and
> replaced by internal ovirt-engine implementation in oVirt Engine 4.4.10.6.
> During upgrade from previous oVirt versions to oVirt 4.4.10
> ovirt-engine-extension-logger-log4j package is uninstalled if it was
> previously installed.
> If you used ovirt-engine-extension-logger-log4j in previous oVirt
> versions, you will need to manually remove existing
> ovirt-engine-extension-logger-log4j
> configuration files and configure the new feature of sending log records
> to remote syslog service according to the Administration Guide.
> Also after successful upgrade to oVirt 4.4.10 you can manually uninstall
> log4j12 package without breaking oVirt setup:
> $ dnf remove log4j12
>
> - [BZ 2044257 ] -
> Bump snmp4j library version to remove dependency on log4j
> oVirt Engine 4.4.10.6 is requiring snmp4j >= 3.6.4, which no longer
> depends on log4j library
>
>
> --
>
> 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.*
>
>
>
> ___
> Users mailing list -- us...@ovirt.org
> To unsubscribe send an email to users-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/us...@ovirt.org/message/E4FWI26XP2VNP5GACYULY3HOBH3CWEIC/
>


-- 
Didi
___
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/TCCEV3G2E26O5VMSNGX3TCDX5BFWFE7Z/

[ovirt-devel] Re: how to UI/API certificates with a valid one (ex: let's encrypt) ? ( as open shift required one )

[Yedidyah Bar David]

On Sun, Jan 23, 2022 at 9:15 AM Eric Tiquet  wrote:
>
> Hello community,
> Would like to use ovirt & openshift, a this might be trivial but I am juste 
> blocked at 'step two'.
> (As openshift refuse to use the ovirt without valid certificates and the 
> insecure workaround does'not work)
>
> I can't find any usefull information to setup the UI/API certificates. ( ex: 
> there is no apache...)
> Could someone please point me to the correct tuto's or instruction ?

Perhaps you were looking for:

https://www.ovirt.org/documentation/administration_guide/index.html#appe-Red_Hat_Enterprise_Virtualization_and_SSL

If not, please provide more details about your problem - what you
try/want to do, what happens, what's expected, etc. Thanks.

Best regards,
-- 
Didi
___
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/CKQ4PDOEI6BVBZHUV5GGBAY3PMDWPK5U/

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

[Yedidyah Bar David]

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...

Best regards,
-- 
Didi
___
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/MJDAXORFA3E6QSUOO3NDIDCA7YHEY3KF/

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

[Yedidyah Bar David]

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?).

Best regards,
-- 
Didi
___
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/KUQODGAKY4G3T4DHV236QLXRDANRUF6Z/

[ovirt-devel] Re: ovirt-release-master - snapshot rpm

[Yedidyah Bar David]

On Wed, Jan 12, 2022 at 11:57 AM lejeczek via Devel  wrote:
>
>
>
> On 12/01/2022 06:37, Yedidyah Bar David wrote:
> > On Tue, Jan 11, 2022 at 9:45 PM lejeczek via Devel  wrote:
> >> Hi guys
> >>
> >> I see 'ovirt-release-master' updates not too rarely, example:
> >>
> >> ..
> >>ovirt-release-master
> >>  noarch
> >> 4.5.0-0.0.master.2022062025.gitc1cee60.el9
> > Are you on CentOS Stream 9? 9 is still not ready. If you are interested
> > in general development, please use 8. Help on 9 support is also welcome.

?

> >
> >> copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
> >> 20 k
> >> ..
> >>
> >> Not knowing how this all works - what is that worth? What
> >> does it do really? No other packages get updated from oVirt
> >> repos.
> > None at all?
> oh,
> and just to make clear:
>
> -> $ dnf repolist | grep ovirt
> copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
> Copr repo for ovirt-master-snapshot owned by ovirt
> ovirt-master-centos-stream-ceph-pacific-testing
> CentOS Stream 9 - Ceph Pacific - testing
> ovirt-master-centos-stream-gluster10-testing
> CentOS Stream 9 - Glusterfs 10 - testing
> ovirt-master-centos-stream-nfv-openvswitch2-testing
> CentOS Stream 9 - NFV OpenVSwitch 2 - testing
> ovirt-master-centos-stream-openstack-yoga-testing
> CentOS Stream 9 - OpenStack Yoga Repository - testing
> ovirt-master-centos-stream-opstools-collectd5-testing
> CentOS Stream 9 - OpsTools - Collectd 5 - testing
> ovirt-master-centos-stream-ovirt45-testing
> CentOS Stream 9 - oVirt 4.5 - testing
> ovirt-master-ioprocess-preview
> Copr repo for ioprocess-preview owned by nsoffer
> ovirt-master-ovirt-imageio-preview
> Copr repo for ovirt-imageio-preview owned by nsoffer
>
> or perhaps nothing among rpms I have installed from oVirt
> repos - and I do not have that many, true.

Please explain exactly what you do, what happens, and what you expect.
Obviously, if you install nothing from oVirt repos, you'll not
get updates from there.

As explained above, there is not that much interesting stuff
right now for el9, unless you are interested in helping with
this specifically.

Best regards,
-- 
Didi
___
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/UVCHTOV3BGBEQ7QRTQTL4TU4AYUMBQQS/

[ovirt-devel] Re: Change in ovirt-engine[master]: packaging: engine-setup: Use otopi's checkForSafeUpdate

[Yedidyah Bar David]

On Wed, Jan 12, 2022 at 12:06 PM Code Review  wrote:
>
> From Jenkins CI :
>
> Jenkins CI has posted comments on this change. ( 
> https://gerrit.ovirt.org/c/ovirt-engine/+/116920 )
>
> Change subject: packaging: engine-setup: Use otopi's checkForSafeUpdate
> ..
>
>
> Patch Set 6:
>
> Build Failed
>
> https://jenkins.ovirt.org/job/standard-enqueue/36418/ :
> This change was not submitted to any change queues for system testing. You 
> will need to create some 'build-artifacts' jobs if you want changes to be 
> submitted to change queues, take part in the system tests and be deployed to 
> the nightly snapshot repositories. If your project uses STDCI V2 and you have 
> release branches configured, you may disregard this message.
>
>
> https://jenkins.ovirt.org/job/ovirt-engine_standard-on-merge/2762/ : UNSTABLE

I think it's because of:

[2022-01-12T09:42:30.703Z] Traceback (most recent call last):
[2022-01-12T09:42:30.703Z]   File
"/home/jenkins/agent/workspace/ovirt-engine_standard-on-merge@tmp/durable-ecea2c02/script.sh",
line 10, in 
[2022-01-12T09:42:30.703Z] change = GerritMergedChange.from_jenkins_env()
[2022-01-12T09:42:30.703Z]   File
"/home/jenkins/agent/workspace/ovirt-engine_standard-on-merge/jenkins/stdci_libs/change_queue/changes/__init__.py",
line 290, in from_jenkins_env
[2022-01-12T09:42:30.703Z] o =
cls(gerrit_patchset=GerritPatchset.from_jenkins_env())
[2022-01-12T09:42:30.703Z]   File
"/home/jenkins/agent/workspace/ovirt-engine_standard-on-merge/jenkins/stdci_libs/gerrit.py",
line 157, in from_jenkins_env
[2022-01-12T09:42:30.703Z] 'GERRIT_PATCHSET_UPLOADER', env
[2022-01-12T09:42:30.703Z]   File
"/home/jenkins/agent/workspace/ovirt-engine_standard-on-merge/jenkins/stdci_libs/gerrit.py",
line 97, in from_jenkins_env
[2022-01-12T09:42:30.703Z] return cls(env[prefix + '_NAME'],
env[prefix + '_EMAIL'])
[2022-01-12T09:42:30.703Z]   File "/usr/lib64/python3.6/os.py", line
669, in __getitem__
[2022-01-12T09:42:30.703Z] raise KeyError(key) from None
[2022-01-12T09:42:30.703Z] KeyError: 'GERRIT_PATCHSET_UPLOADER_NAME'

and I *think* it's because I commented 'ost check' on two patches,
which were one above the other, and CI merged the upper one before
finishing the gating of the lower one (current).

Current case can most probably be ignored, but I wonder if we want to
do something in the general case - perhaps the code already does
everything well, didn't check - e.g. checking that all pending patches
in the stack have all acks, etc.

Best regards,
-- 
Didi
___
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/6RBUEGF3TAHJKVQLN564U2A4B32EAVWC/

[ovirt-devel] [Action Required] otopi updated

[Yedidyah Bar David]

Hi all,

I now merged these patches:

https://github.com/oVirt/otopi/pull/11
https://gerrit.ovirt.org/c/ovirt-engine/+/116920
https://gerrit.ovirt.org/c/ovirt-engine/+/118228

Please update otopi on your dev machines. Otherwise, engine-setup might fail.

Best regards,
-- 
Didi
___
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/5QSNXIYN5M4BJO6OR2XSWSEEYXMOD5KJ/

[ovirt-devel] Re: ovirt-release-master - snapshot rpm

[Yedidyah Bar David]

On Tue, Jan 11, 2022 at 9:45 PM lejeczek via Devel  wrote:
>
> Hi guys
>
> I see 'ovirt-release-master' updates not too rarely, example:
>
> ..
>   ovirt-release-master
> noarch
> 4.5.0-0.0.master.2022062025.gitc1cee60.el9

Are you on CentOS Stream 9? 9 is still not ready. If you are interested
in general development, please use 8. Help on 9 support is also welcome.

> copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot
> 20 k
> ..
>
> Not knowing how this all works - what is that worth? What
> does it do really? No other packages get updated from oVirt
> repos.

None at all?

Some packages are still not built for el9, due to various reasons.
But some are, including ones that are updated often.

The copr UI does not make it very easy to see which package was
built when for a specific arch, but you can find this via:

1. Go to copr ovirt master snapshot project page:

https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/

2. Go to Builds, then choose a build that's done also for el9 -
not sure how you can know this, you have to guess, e.g. vdsm:

https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/build/3144016/

3. Go to the chroot for one of the el9 builds:

https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/03144016-vdsm/

4. Then press '..' to go to parent dir - this one will have all
builds of all packages for this arch:

https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/

5. Then press "Last Modified", and you can see which ones are
newest, so should have been expected to be updated recently
on your machine.

> Care to shed bit of light?

I hope this clarifies. If it's not enough, please provide more
details about what you try to do and what problems you notice.

Best regards,
-- 
Didi
___
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/J2ZCPTH4HMX5SJTSS2JTFAPZR6FE4ZHJ/

[ovirt-devel] Re: [oVirt/ovirt-release] Failed repoclosure job (Issue #60)

[Yedidyah Bar David]

(Adding Artur. About the engine, I was referring to
https://gerrit.ovirt.org/c/ovirt-engine/+/116811 )

On Wed, Jan 5, 2022 at 1:32 PM Yedidyah Bar David  wrote:
>
> On Wed, Jan 5, 2022 at 1:09 PM github-actions[bot]  
> wrote:
>>
>> ❌ The repoclosure CI job is still failing. Please investigate.
>
>
> It failed because we recently started building metrics and dwh on el9, which 
> require stuff we do not have:
> - The engine, already discussed elsewhere, patches are WIP (apparently 
> waiting for Artur? Not sure).
> - ansible. No idea why it's missing.
>
> Perhaps better not build new stuff on el9 before we fix these, or stop 
> running repoclosure on el9 for now.
>
> Best regards,
> --
> Didi



-- 
Didi
___
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/YOCEEBC4UF7KJPQANOSLS2K4HUDVWO3B/

[ovirt-devel] Re: [oVirt/ovirt-release] Failed repoclosure job (Issue #60)

[Yedidyah Bar David]

On Wed, Jan 5, 2022 at 1:09 PM github-actions[bot] 
wrote:

> ❌ The repoclosure CI job is still failing. Please investigate.
> 
>

It failed because we recently started building metrics and dwh on el9,
which require stuff we do not have:
- The engine, already discussed elsewhere, patches are WIP (apparently
waiting for Artur? Not sure).
- ansible. No idea why it's missing.

Perhaps better not build new stuff on el9 before we fix these, or stop
running repoclosure on el9 for now.

Best regards,
-- 
Didi
___
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/BJ3YVNKYFP74K5MM3GPIBWDC5YFWRZTR/

[ovirt-devel] Re: git backup

[Yedidyah Bar David]

On Tue, Jan 4, 2022 at 2:20 PM Michal Skrivanek
 wrote:
>
> It would be great if we can mirror it vice versa, to gerrit. It would help 
> with some parts of our automation.
> But I'm not sure it's that easy to do...

You mean gerrit.ovirt.org? Do we even intend to keep maintaining it
going forward? I had a feeling we won't, or at most a read-only static
copy, generated once when all projects finish migrating.

Anyway, this will fall into my (2.) below, which is probably the most
expensive work-wise, but is obviously any developer's instinctive first,
or even only, reply...

I think keeping gerrit.ovirt.org?'s content is an important item on its
own.

>
> > On 29. 12. 2021, at 11:36, 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?
> >
> > [1] https://archiveprogram.github.com/
> >
> > Best regards,
> > --
> > Didi
> > ___
> > 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/LP3IZ67IUERRWTW4CDBJPGQPBCYHFGVP/
>


-- 
Didi
___
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/FOWAQOYOZHGIEK4C2N4JXO4AQUE77O56/

[ovirt-devel] git backup

[Yedidyah Bar David]

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?

[1] https://archiveprogram.github.com/

Best regards,
-- 
Didi
___
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/LP3IZ67IUERRWTW4CDBJPGQPBCYHFGVP/

[ovirt-devel] Re: [oVirt/ovirt-release] Failed repoclosure job (Issue #55)

[Yedidyah Bar David]

On Mon, Dec 27, 2021 at 8:55 PM Martin Perina  wrote:
>
>
>
> On Mon, 27 Dec 2021, 16:17 Yedidyah Bar David,  wrote:
>>
>> On Mon, Dec 27, 2021 at 2:38 PM github-actions[bot]
>>  wrote:
>> >
>> > ❌ The repoclosure CI job is still failing. Please investigate.
>>
>> I think this started failing recently (on el9) due to a combination of:
>>
>> - The engine is still not built on el9 in copr. I tried building
>> it myself there and so far got stuck - it seems like the fix is
>> an existing pending patch [1] (failed at %add_maven_depmap).
>>
>> - ovirt-engine-keycloak is now built also for el9, but requires an
>> engine package, so we fail on repoclosure.
>
>
> I've tried to remove existing EL9 build and disable further EL9 builds for 
> Keycloak, but probably I've missed something.

Yes, I now see that you did. Thanks.

> So if the correct removal can be done, it seems easier for now

I deleted all the previous builds, that did include el9. Not sure if
there is a better way. This is for all chroots - so also el8 now has
only the last two builds. Let's see if this helps.

Best regards,
-- 
Didi
___
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/Y5IYYMV7NC2YFYMNDANQBGW47QFUB4K3/

[ovirt-devel] Re: [oVirt/ovirt-release] Failed repoclosure job (Issue #55)

[Yedidyah Bar David]

On Mon, Dec 27, 2021 at 2:38 PM github-actions[bot]
 wrote:
>
> ❌ The repoclosure CI job is still failing. Please investigate.

I think this started failing recently (on el9) due to a combination of:

- The engine is still not built on el9 in copr. I tried building
it myself there and so far got stuck - it seems like the fix is
an existing pending patch [1] (failed at %add_maven_depmap).

- ovirt-engine-keycloak is now built also for el9, but requires an
engine package, so we fail on repoclosure.

Unless we have concrete plans to fix this very soon, I suggest to
stop the noise for now - either not build (or publish?) keycloak
for el9, or do not run repoclosure on el9, or perhaps filter the
output to not fail if it's only on these packages, etc.

[1] https://gerrit.ovirt.org/c/ovirt-engine/+/116811
-- 
Didi
___
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/AWEGJ5MRLIAEW2EPMRS5MH7JBMJ5DZFT/

[ovirt-devel] Re: OST fails with "Error loading module from /usr/share/ovirt-engine/modules/common/org/springframework/main/module.xml"

[Yedidyah Bar David]

On Fri, Dec 24, 2021 at 1:06 PM Marcin Sobczyk  wrote:
>
> Hi All,
>
> OST currently fails all the time during engine setup.
> Here's a piece of ansible log that's seen repeatedly and I think
> describes the problem:
>
> 11:07:54 E "engine-config",
> 11:07:54 E "-s",
> 11:07:54 E "OvfUpdateIntervalInMinutes=10"
> 11:07:54 E ],
> 11:07:54 E "delta": "0:00:01.142926",
> 11:07:54 E "end": "2021-12-24 11:06:37.894810",
> 11:07:54 E "invocation": {
> 11:07:54 E "module_args": {
> 11:07:54 E "_raw_params": "engine-config -s
> OvfUpdateIntervalInMinutes='10' ",
> 11:07:54 E "_uses_shell": false,
> 11:07:54 E "argv": null,
> 11:07:54 E "chdir": null,
> 11:07:54 E "creates": null,
> 11:07:54 E "executable": null,
> 11:07:54 E "removes": null,
> 11:07:54 E "stdin": null,
> 11:07:54 E "stdin_add_newline": true,
> 11:07:54 E "strip_empty_ends": true,
> 11:07:54 E "warn": false
> 11:07:54 E }
> 11:07:54 E },
> 11:07:54 E "item": {
> 11:07:54 E "key": "OvfUpdateIntervalInMinutes",
> 11:07:54 E "value": "10"
> 11:07:54 E },
> 11:07:54 E "msg": "non-zero return code",
> 11:07:54 E "rc": 1,
> 11:07:54 E "start": "2021-12-24 11:06:36.751884",
> 11:07:54 E "stderr": "Picked up JAVA_TOOL_OPTIONS: -Dcom.redhat.fips=false",
> 11:07:54 E "stderr_lines": [
> 11:07:54 E "Picked up JAVA_TOOL_OPTIONS: -Dcom.redhat.fips=false"
> 11:07:54 E ],
> 11:07:54 E "stdout": "Error loading module from
> /usr/share/ovirt-engine/modules/common/org/springframework/main/module.xml",
> 11:07:54 E "stdout_lines": [
> 11:07:54 E "Error loading module from
> /usr/share/ovirt-engine/modules/common/org/springframework/main/module.xml"
>
> We do set some config values for the engine in OST when running
> engine-setup. I tried commenting these out, but then engine failed
> health check anyway:
>
> "Status code was 503 and not [200]: HTTP Error 503: Service Unavailable"
>
> The last working set of OST images was the one from Dec 23, 2021 2:05:08
> AM. The first broken one is from Dec 24, 2021 2:05:09 AM. The shipped
> ovirt-engine RPMs doesn't seem to contain any important changes for
> these two sets, but AFAICS the newer ovirt-dependencies RPM did take in
> a couple of patches that look suspicious [1][2][3]. The patches were
> merged on November 16th, but it seems they were first used in that
> broken set from Dec 24 (the one from Dec 23 seems to contain
> ovirt-dependencies RPM based on this [4] commit).
>
> I wanted to try out an older version of ovirt-dependencies, but I think
> they were wiped out from resources.ovirt.org.
>
> I will disable cyclic el8stream OST runs for now, cause all of them
> fail. If there's anyone working and able to make a build with those
> patches reverted and test that out, please ping me and I'll re-enable them.
>
> Regards, Marcin
>
> [1] https://gerrit.ovirt.org/c/ovirt-dependencies/+/114699
> [2] https://gerrit.ovirt.org/c/ovirt-dependencies/+/113877

This is the one that broke us - it replaced a set of shell scripts
with maven. These scripts also created:

# ls -l /usr/share/java/ovirt-dependencies/4.4
total 0
lrwxrwxrwx. 1 root root 24 Nov  4 18:00 gwt-servlet.jar ->
../gwt-servlet-2.9.0.jar
lrwxrwxrwx. 1 root root 31 Nov  4 18:00 spring-aop.jar ->
../spring-aop-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 33 Nov  4 18:00 spring-beans.jar ->
../spring-beans-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 35 Nov  4 18:00 spring-context.jar ->
../spring-context-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 32 Nov  4 18:00 spring-core.jar ->
../spring-core-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 38 Nov  4 18:00 spring-expression.jar ->
../spring-expression-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 38 Nov  4 18:00 spring-instrument.jar ->
../spring-instrument-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 32 Nov  4 18:00 spring-jdbc.jar ->
../spring-jdbc-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 32 Nov  4 18:00 spring-test.jar ->
../spring-test-5.0.4.RELEASE.jar
lrwxrwxrwx. 1 root root 30 Nov  4 18:00 spring-tx.jar ->
../spring-tx-5.0.4.RELEASE.jar

But now there is no '4.4' directory. The engine spec still has:
%global ovirt_dependencies ovirt-dependencies/4.4

despite being at 4.5 and despite also ovirt-dependencies being
bumped to 4.5 a few days ago.

Not sure what the exact plans are regarding this change - if it's
just a bug, I'll let Martin/Artur fix (by perhaps adding a 4.5
directory with links and point the 4.5 engine there, or make it
provide both - not sure what the plans are). I did not try to
revert, anyway, because quite many other related patches were
merged since, including the move to github/copr.

For now, I pushed this simple workaround to OST [1]:

# ln -s . /usr/share/java/ovirt-dependencies/4.4
# ls -l /usr/share/java/ovirt-dependencies/
total 4724
lrwxrwxrwx. 1 root root   1 Dec 27 08:28 4.4 -> .
-rw-r--r--. 1 root root  360096 Dec 26 23:39 spring-aop.jar
-rw-r--r--. 1 root root  654084 Dec 26 23:39 spring-beans.jar
-rw-r--r--. 1 root root 1079129 Dec 26 23:39 spring-context.jar
-rw-r--r--. 1 root root 1216476 

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

[Yedidyah Bar David]

On Sun, Nov 28, 2021 at 11:49 AM Nir Soffer  wrote:
>
> 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

+1, happens to me as well. Pushed a workaround disabling el9 for my case:

https://gerrit.ovirt.org/c/ovirt-hosted-engine-setup/+/117828

Best regards,
-- 
Didi
___
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/H7RLODBYSR3AAAI7DPSGWK5VYLTESGQ4/

[ovirt-devel] Re: Failed CI for engine patches - java-client-kubevirt otopi

[Yedidyah Bar David]

On Fri, Nov 26, 2021 at 11:36 AM Sandro Bonazzola 
wrote:

>
>
> Il giorno gio 25 nov 2021 alle ore 20:46 Ehud Yonasi 
> ha scritto:
>
>> Indeed Martin, I can see it now.
>> We have an issue reflecting the new resources server, probably dns or
>> something related.
>>
>> Meanwhile Shani, I suggest that you change the resources server in your
>> automation/*.repos file to:
>> https://resources02.phx.ovirt.org/repos/ovirt/tested/master/rpm/el8
>>
>> We have someone already looking into it already and we hope CI will be
>> fixed soon.
>> Apologies.
>>
>
> Please don't require any ovirt.org repository anymore in build roots of
> any test or build job.
> Either use CentOS Virt SIG repos or COPR repos.
> We are dismissing ovirt-master-snapshot completely.
>

Do you have an example for a project already doing this?

I now ran into a similar issue and pushed:

https://gerrit.ovirt.org/c/ovirt-hosted-engine-setup/+/117827

Before pushing it, I quickly skimmed through what-seems-like-relevant
threads in my
inbox and didn't find an existing example. Perhaps this is the wrong way to
do this,
and we should instead use github actions for check-patch. Was this
discussed? Decided?


Thanks and best regards,


>
>
>
>
>>
>> On 25 Nov 2021, at 18:03, Martin Perina  wrote:
>>
>>
>>
>> On Thu, Nov 25, 2021 at 2:04 PM Ehud Yonasi  wrote:
>>
>>> So I am not sure where the dependency came from, but as I can see from
>>> otopi repo it is only realsing to ovirt-4.3 on resources at the moment.
>>>
>>
>> Not true, otopi is configured correctly:
>>
>> master -> ovirt-master
>> https://github.com/oVirt/otopi/blob/master/.ovirtci.yaml
>>
>> otopi-1..9 -> ovirt-4.4
>> https://github.com/oVirt/otopi/blob/otopi-1.9/.ovirtci.yaml
>>
>> Similar situation is with java-client-kubevirt, which should also be
>> correctly setup:
>>
>> master -> ovirt-master, ovirt-4.4
>> https://github.com/oVirt/java-client-kubevirt/blob/master/.stdci.yaml
>>
>> And I had to mention that similar situation we had for
>> ovirt-jboss-modules-maven-plugin, which magically disappeared from tested
>> repo cca 2 weeks ago and I needed to re-merge last patch to get the build
>> there again. And also here everything seems correct to me:
>>
>>
>> https://github.com/oVirt/ovirt-jboss-modules-maven-plugin/blob/master/automation.yaml
>>
>>
>> All of those packages are included in oVirt project for quite long time,
>> so the issue is somewhere in the Jenkins CI
>>
>>
>>> Maybe Sandro can help with that?
>>>
>>> On Thu, Nov 25, 2021 at 2:46 PM Shani Leviim  wrote:
>>>
 Hi Ehud,
 Honestly - I have no idea.
 This failure is from today, but in the patches, there is a series of CI
 failures while trying to build the patch - all failures while trying to
 build the engine.


 *Regards,*

 *Shani Leviim*


 On Thu, Nov 25, 2021 at 2:19 PM Ehud Yonasi  wrote:

> Hi Shani and Artur,
>
> I didn't find otopi and that java-client-kubevirt package in the repos
> listed inside the run. was it there in the first place?
>
> Artur, It seems the centos mirrors were not available during the time
> of the build, could you please re-trigger it and update if it's working 
> for
> you now?
>
> Thanks,
> Ehud.
>
> On Thu, Nov 25, 2021 at 1:28 PM Artur Socha  wrote:
>
>> I could also add that I am currently having an issue with accessing
>> Centos stream 8 AppStream repo (timed out). See [1] . Perhaps that 
>> somehow
>> related?
>>
>> [1]
>> https://jenkins.ovirt.org/job/vdsm-jsonrpc-java_standard-check-patch/187/console
>>
>> Artur
>>
>> On Thu, Nov 25, 2021 at 11:50 AM Shani Leviim 
>> wrote:
>>
>>> Hi,
>>> I have a series of engine patches that keep failing although the
>>> chain is rebased on the latest master.
>>> I ran 'ci build' a couple of minutes ago and it failed with this one:
>>> 11:08:45 No match for argument: otopi
>>> 11:08:45 Error: Unable to find a match: java-client-kubevirt otopi
>>>
>>> https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15286/console
>>>
>>> The engine patches:
>>>
>>> https://gerrit.ovirt.org/q/topic:%22copy-template-mbs-disk%22+(status:open%20OR%20status:merged)
>>>
>>> Can someone assist, please?
>>>
>>>
>>> *Regards,*
>>>
>>> *Shani Leviim*
>>> ___
>>> 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/VUYJRGNY6X7UYZ6PQBQGVENE5LVFGN3O/
>>>
>>
>>
>> --
>> Artur Socha
>> Senior Software Engineer, RHV
>> Red Hat
>> 

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

[Yedidyah Bar David]

On Wed, Nov 17, 2021 at 2:34 PM Danilo de Paula  wrote:
>
>
>
> On Wed., Nov. 17, 2021, 4:54 a.m. Yedidyah Bar David,  wrote:
>>
>> On Wed, Nov 17, 2021 at 9:44 AM Sandro Bonazzola  wrote:
>>>
>>>
>>>
>>> Il giorno mer 17 nov 2021 alle ore 03:12 Danilo de Paula 
>>>  ha scritto:
>>>>
>>>> Since you're consuming the CentOS Stream 8 packages (I assume) and the
>>>> CentOS Stream 8 is actually the opened development of the next RHEL minor 
>>>> release (8.6) [1], it makes
>>>> a lot of sense to open BZs against those packages in RHEL-8.6.
>>>>
>>>> Especially since we won't fix those problems in CentOS Stream without 
>>>> fixing it in RHEL first.
>>>>
>>>> So, if you believe that this is a problem with the package itself (as it 
>>>> looks like), I strongly suggest opening a BZ against those packages in 
>>>> RHEL.
>>>
>>>
>>> Didi can you please open a bug against RHEL 8 CentoStream version for 
>>> qemu-kvm component?
>>
>>
>> Michal searched and found:
>>
>> https://gitlab.com/qemu-project/qemu/-/issues/641
>>
>> And indeed it seems to be our case:
>>
>> [root@ost-he-basic-suite-master-host-0 ~]# ps uaxww | grep qemu | sed 's/ 
>> /\n/g' | grep ^pcie-root-port | wc
>>  17  171160
>>
>> Danilo - the gitlab page above mentions several patches linking to it 
>> already, some of which from the last few days. I didn't check them. Is there 
>> still value in opening a bug, or is the issue already sufficiently clear?
>
>
> That's a good question.
> See, we don't track gitlab issues, the upstream project does.
> So, unless those patches are included in the qemu 6.2 upstream release 
> (should happen in a few days, I think rc1 is about to be out), they need to 
> be backported in RHEL (when rhel rebases). And we only do backports with RHEL 
> BZs.
>
> I see some commits being mentioned but the issue is still not closed.
> So wait a few days and see. If it's not fixed by rc4, then I suggest open a 
> BZ for the backports.
>
> I expect the rebase to be concluded by the beginning of December btw.

Thanks. Now filed this Stream bug:

https://bugzilla.redhat.com/show_bug.cgi?id=2024605

IMO waiting till beginning of Dec is too late. We already got a few
reports on the users list by people hitting this.
If it's too much work to fix/revert, perhaps consider excluding this
on centos-release package, repo, whatever.

Thanks!
-- 
Didi
___
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/BZ63TLATE5QDFXFGWKAY4CM5GE2XL5FR/

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

[Yedidyah Bar David]

On Wed, Nov 17, 2021 at 9:44 AM Sandro Bonazzola 
wrote:

>
>
> Il giorno mer 17 nov 2021 alle ore 03:12 Danilo de Paula <
> ddepa...@redhat.com> ha scritto:
>
>> Since you're consuming the CentOS Stream 8 packages (I assume) and the
>> CentOS Stream 8 is actually the opened development of the next RHEL minor
>> release (8.6) [1], it makes
>> a lot of sense to open BZs against those packages in RHEL-8.6.
>>
>> Especially since we won't fix those problems in CentOS Stream without
>> fixing it in RHEL first.
>>
>> So, if you believe that this is a problem with the package itself (as it
>> looks like), I strongly suggest opening a BZ against those packages in RHEL.
>>
>
> Didi can you please open a bug against RHEL 8 CentoStream version for
> qemu-kvm component?
>

Michal searched and found:

https://gitlab.com/qemu-project/qemu/-/issues/641

And indeed it seems to be our case:

[root@ost-he-basic-suite-master-host-0 ~]# ps uaxww | grep qemu | sed 's/
/\n/g' | grep ^pcie-root-port | wc
 17  171160

Danilo - the gitlab page above mentions several patches linking to it
already, some of which from the last few days. I didn't check them. Is
there still value in opening a bug, or is the issue already sufficiently
clear?

That said, I failed to verify this using isa-debugcon as mentioned there,
and the various things the command uses (FDs, storage) are temporary -
created on the fly by libvirt/vdsm - so I can't just copy the command and
add a few options. If needed I guess it's possible to hack this using a
vdsm hook or something.

For the time being, is there a workaround/temporary-build/whatever other
than downgrading to qemu-kvm-6.0.0 (which is considered deprecated, I guess
- e.g. Sandro is going to remove it from ovirt-release package (
https://github.com/oVirt/ovirt-release/pull/2 ), following the thread
"[CentOS-devel] Is advanced-virt (Virtualization SIG) not relevant anymore
with latest CentOS Stream 8?")?


>
>
>
>>
>> [1] - This is only true for CentOS Stream 8 (which is a copy of RHEL).
>> CentOS Stream 9 is the other way around.
>>
>
> Sadly no, from my experience it's still fix in rhel first and then in
> CentOS Stream, at least for systemd on CentOS Stream 9.
> I would love to see fixes coming to Stream first.
>

Best regards,

-- 
Didi
___
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/VN4YUIYKJLIRPMFPWGZRXGU2J44QURIB/

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

[Yedidyah Bar David]

On Tue, Nov 16, 2021 at 12:42 PM Nir Soffer  wrote:
>
> 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 
>>  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?

With virt-install:

https://github.com/oVirt/ovirt-ansible-collection/blob/master/roles/hosted_engine_setup/tasks/bootstrap_local_vm/02_create_local_vm.yml#L96

>
> 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?

It seems so, yes.

>
>>>
>>>
>>> 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&qu

[ovirt-devel] oVirt SDK docs services.m.html cut in the middle

[Yedidyah Bar David]

Hi all,

I was searching for something in the SDK and noticed that [1] is cut
in the middle. The last class that appears there is 'TemplateService'.
If you scroll down on the left pane and press something below this
one, such as [2], you see that the right pane does not scroll down -
you are at (close to) its bottom. The last link that seems to be
included is [3]. Known issue?

Thanks,

[1] https://ovirt.github.io/ovirt-engine-sdk/master/services.m.html

[2] 
https://ovirt.github.io/ovirt-engine-sdk/master/services.m.html#TemplateCdromService

[3] 
https://ovirt.github.io/ovirt-engine-sdk/master/services.m.html#TemplateService.export_to_path_on_host
-- 
Didi
___
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/FYPODDPHBVSWBIXH74AXBNWVQJ4T4F7E/

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

[Yedidyah Bar David]

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?


> 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.

Best regards,
-- 
Didi
___
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/YW2LM73CUAM3BZ6OQ7W5OGTWVQ6TIMPK/

[ovirt-devel] Re: [External] : Re: Need to complie kmod-cxgb3

[Yedidyah Bar David]

On Wed, Oct 20, 2021 at 9:57 AM Sandro Bonazzola 
wrote:

>
>
> Il giorno ven 15 ott 2021 alle ore 18:27 Marcos Sungaila <
> marcos.sunga...@oracle.com> ha scritto:
>
>> Hi Sandro,
>>
>>
>>
>> From my findings, the engine-setup command will not work out-of-box on
>> any other distro than centos, rhel or ibm-powerkvm.
>>
> I intend to submit a patch to the otopi package to allow the engine-setup
>> command to run on Oracle Linux too.
>>
> Also, I intend to submit other patches regarding OS validation for other
>> components.
>>
>> May I suggest we turn the OS validation more generic or include other
>> distros like you mentioned in the previous e-mail?
>>
>
> Sure! If you're hitting issues on deploying on any RHEL 8 / CentOS Stream
> 8 derivatives feel free to open a bz and, if you can, send patches!
>

You might want to use something like:

https://gerrit.ovirt.org/c/ovirt-engine/+/114663

Best regards,
-- 
Didi
___
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/N7LMOPLHMT5FEWAA6SSR3JMUQHQAFG7G/

[ovirt-devel] Re: Introduction

[Yedidyah Bar David]

Hi Maithreyi,

On Mon, Oct 18, 2021 at 12:21 PM Maithreyi Gopal 
wrote:

> Hello,
>
> 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.
>
> 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.

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...

Good luck and best regards,
-- 
Didi
___
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/ZPZADSXF5HAEPBPNCHKQIMT3SGS2JMCK/

[ovirt-devel] Re: ovirt-engine-extension-aaa-ldap broken, if using CNAME for LDAP server DNS

[Yedidyah Bar David]

On Wed, Sep 8, 2021 at 2:36 AM Erdősi Péter 
wrote:

> Hello!
>
> We're started the upgrade one of our oVirt clusters to the recent 4.4
> minor version (4.4.8.5-1.el8) and we found a bug in the recent change of
> the aaa-ldap plugin.
> This bug came along after the IPv4/IPv6 selection introduced in
> ovirt-engine-extension-aaa-ldap 1.4.4
>
> We've dig down in the rabbit hole, and it looks like, our DNS solution is
> just not compatible with the plugin after this commit:
> https://github.com/oVirt/ovirt-engine-extension-aaa-ldap/commit/4c0f2e72df88ce653ce552057554465fb901820f
>
> I don't know, how the industry actually use CNAME records, but we have a
> rule, that we use independet DNS names for services, and machines itself.
> This become handy, when you migrate/upgrade services, like LDAP to another
> machine, and I think, this should be supported.
>
> Our LDAP server service domain is actually ldap-master.niif.hu and
> ldap.niif.hu, but in real, there are two servers, which actually have
> their own FQDNs.
>
> The actual DNS structure:
>
> host -t CNAME ldap-master.niif.hu
> ldap-master.niif.hu is an alias for elm.niif.hu.
>
> host -t CNAME ldap.niif.hu
> ldap.niif.hu is an alias for holly.ldap.einfra.hu.
>
> host elm.niif.hu
> elm.niif.hu has address 193.225.14.175
> elm.niif.hu has IPv6 address 2001:738:0:701::3
>
> host holly.ldap.einfra.hu
> holly.ldap.einfra.hu has address 193.224.92.6
> holly.ldap.einfra.hu has IPv6 address 2001:738:0:431::6
>
> The commit above (as far as I understand) only tries to resolve A and 
> records in DNS, and drop the connection if it not found. Of course, the
> certificate only have ldap-master and ldap.niif.hu in it, so using holly
> end elm does not solve the problem (also, if the service will be migrated,
> the service domain will be kept, but not the machine's FQDN, since we
> cannot afford to shut down one of our LDAP server for a migration windows.
>
> We've tried to downgrade the package to 1.4.3, which is works fine.
>
> The actual error looks like this (engine.log)
>
> 2021-09-07 15:53:09,833+02 WARN
> [org.ovirt.engine.extension.aaa.ldap.AuthnExtension] (default task-1) []
> [ovirt-engine-extension-aaa-ldap.authn::NIIFLdap-authn] Cannot initialize
> LDAP framework, deferring initialization. Error: An error occurred while
> attempting to connect to server ldap-master.niif.hu:636:
> IOException(LDAPException(resultCode=91 (connect error), errorMessage='An
> error occurred while attempting to establish a connection to server
> ldap-master.niif.hu/193.225.14.175:636:  UnknownHostException(
> ldap-master.niif.hu), ldapSDKVersion=4.0.14,
> revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> 2021-09-07 15:53:09,833+02 ERROR
> [org.ovirt.engine.core.sso.servlets.InteractiveAuthServlet] (default
> task-1) [] Internal Server Error: An error occurred while attempting to
> connect to server ldap-master.niif.hu:636:
> IOException(LDAPException(resultCode=91 (connect error), errorMessage='An
> error occurred while attempting to establish a connection to server
> ldap-master.niif.hu/193.225.14.175:636:  UnknownHostException(
> ldap-master.niif.hu), ldapSDKVersion=4.0.14,
> revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> 2021-09-07 15:53:09,833+02 ERROR
> [org.ovirt.engine.core.sso.service.SsoService] (default task-1) [] An error
> occurred while attempting to connect to server ldap-master.niif.hu:636:
> IOException(LDAPException(resultCode=91 (connect error), errorMessage='An
> error occurred while attempting to establish a connection to server
> ldap-master.niif.hu/193.225.14.175:636:  UnknownHostException(
> ldap-master.niif.hu), ldapSDKVersion=4.0.14,
> revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> 2021-09-07 15:53:09,854+02 ERROR
> [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-1) []
> server_error: An error occurred while attempting to connect to server
> ldap-master.niif.hu:636:  IOException(LDAPException(resultCode=91
> (connect error), errorMessage='An error occurred while attempting to
> establish a connection to server ldap-master.niif.hu/193.225.14.175:636:
> UnknownHostException(ldap-master.niif.hu), ldapSDKVersion=4.0.14,
> revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
>
> As we tried to run the setup tool, that is also looks broken (after that,
> we've copied the required files to /etc/ovirt-engine/aaa and
> /etc/ovirt-engine/extensions.d/ from other, working hosted engine) so we've
> tested the plugin itself, and the setup too, but no luck.
>
> I think, this (CNAME in DNS) should be working with the plugin.
>
> Could you please investigate this issue? (we're here to help test the
> repaired version/patch, if needed, but not feel the knowledge to create the
> patch ourself)
>

>From very casual skimming of the patch, it seems to me like you should be
able to restore the previous behavior by setting in your conf file
'pool.default.socketfactory.resolver.detectIPVersion = false'. Can you
please try that?

[ovirt-devel] Re: self hosted engine installation stucks in "run engine-setup with answerfile"

[Yedidyah Bar David]

Hi,

On Thu, Sep 9, 2021 at 11:48 AM  wrote:

> Hi, I'm building ovirt-engine and ovirt-engine-appliance rpm on CentOS8.
>

Perhaps explain what you are trying to do that is different from what oVirt
does?


> But when I install ovirt using "hosted-engine --deploy" command using
> local repository that contains the rpms,
> the installation always stucks in "run engine-setup with answerfile".
>
> So I checked engine-setup log in /var/log/ovirt-engine/setup of
> HostedEngineLocal VM, the error log is as follow.
> I've been trying to solve this problem for a long time, but i'm just not
> sure what the problem is.
>
> ---
> 2021-09-08 14:44:23,841+0900 DEBUG otopi.plugins.otopi.dialog.human
> human.queryString:159 query OVESETUP_ENGINE_DB_PASSWORD
> 2021-09-08 14:44:23,842+0900 DEBUG otopi.plugins.otopi.dialog.human
> dialog.__logString:204 DIALOG:SEND Engine database password:
>

This is a prompt for the "engine database password". It should not normally
appear in the log. By default, we use automatic DB provisioning and so
generate a random password (and do not prompt for one). Perhaps compare
your answer file with the one in the standard appliance?

Best regards,
-- 
Didi
___
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/TTASKFS2ZWU7EZOVBFVYAUXJKCU3KUZJ/

[ovirt-devel] Re: oVirt 4.3 -> 4.4 upgrade and Self hosted HE storage migration

[Yedidyah Bar David]

Hi,

On Sun, Sep 5, 2021 at 9:19 AM  wrote:
>
> Hy!
>
> I've just finished the process in the subject, and want to share a few things 
> with others, and also want to ask a question.

Thanks :-)

>
> Long story "short" (it's my IT infra@home, I've oVirt in bigger setups at 
> work): I had 3 machines before: two desktop, and one Dell R710 server. One of 
> the desktop running FreeNAS with an SSD RAID1, the other desktop and my Dell 
> machine was my two hypervisors. Luckily, i've just got two HP DL380 G6, which 
> become my hypervisors, and my Dell machine became the TrueNAS storage 
> (redundant PSU, more core, more RAM, more disk :) ).
>
> When I started the procedure, I used the latest oVirt 4.3, but it was the 
> time to upgrade the version, and also want to migrage all my Data (with the 
> self hosted engine too) to the TrueNAS Dell machine (but... I've only have 
> the two SSD on my old FreeNAS, so it has to be moved)
>
> After I replaced the hypervisors, and migrated all my VM data to the new 
> storage to new disks (iSCSI->iSCSI, live and cold storage migration) it was 
> the time, to shut off the FreeNAS, and start the HE redeploy.
>
> The main steps, what I take:
>  - Undeployed the hosted-engine from the host with ID: 2 (the ID came from 
> hosted-engine --vm-status command, the machine name is: Jupiter)
>  - Moved all my VMs to this host, only the HE remained on the machine with 
> ID: 1 (name: Saturn)
>  - Removed the remained stuff with: "hosted-engine --clean-metadata 
> --host-id=2 --force-clean", so the Saturn was the only machine capable of 
> running the HE
>  - Set Global maintenance mode=true
>  - Stop the ovirt-engine in the old HE machine
>  - Create a backup with "engine-backup --mode=backup --file=engine.backup 
> --log=engine-backup.log" and copy it to an another machine (my desktop 
> actually)
>  - "hosted-engine --vm-shutdown"
>  - Saturn shutdown, 4.4.6 installer in (it was written to DVD before, don't 
> want to create another) Saturn complete reinstall.
>  - FreeNAS shutdown, SSD moved to TrueNAS, RAID 1/zVol create, iSCSI export...
>  - After the base network was created, and the backup was moved back to the 
> new Saturn, I started the new host deploy with: "hosted-engine --deploy 
> --restore-from-file=engine.backup"
>
> Catch 1 and 2: If you do this, you must know the old DC and the Cluster name!

Are you sure you _must_? I think it will create new DC/cluster for you
if you type new names. Obviously, this might not be what you want.
So probably what you mean is something like:

If I restore from backup, I think the tool should check the DC/cluster
names in the backup, and let me select among them, perhaps even try to
intelligently guess the one that should be default (or just pick one
at random).

I agree this makes sense, you are welcome to file an RFE bug.
Not sure it will be prioritized - patches are welcome!

> write it down somewhere! or you need to get out the PSQL dbs from the backup, 
> and extract from it... (like i had to)

Would also be useful if you detail your commands as a workaround, if
you file such a bug.

> The process goes almost flawless, but at some point, I've got a deployment 
> error (code: 519) which tells me, the Saturn have missing networks, and I can 
> connect to https://saturn.mope.local:6900/ovirt-engine
>
> Catch 3: this URL not worked, since it was not the HE's URL, and I cannot 
> login because the FQDN checking...

The deploy process temporarily configures the engine to allow using
the host's FQDN to connect to the engine, and forwards port 6900 for
you.

There might have been other complications I do not understand that
prevented this from working well.

What happened when you tried?

If you think this is a real bug, and can reliably reproduce it, please
file one in bugzilla. Thanks!

> This may need some further improvement ;) After some thinking, finally I've 
> made a socks proxy with SSH (1080 forwarded to Saturn) and I was able to 
> login to the locally running HE and make the network changes, which was 
> required to continue the deploy process... Also (since the old FreeNAS box 
> was on my desk, the HE and the two hypervisor was unable to connect to my old 
> SSD iSCSI, so I have to remove it...

I understand this was somewhat annoying, but you have to realize that
there are many different backup/restore/upgrade/migration scenarios,
and it's not easy to decide what's best to do.

In your specific case, if you are confident that you'll not need to be
able to abort in the middle and revert to the old engine+storage, you
could have removed it from the engine before taking the backup.

> (cannot put on maintenance, but I was able to delete it from Storage->Domains 
> tab) After this, Saturn came up, got the "green arrow", so I removed the lock 
> file which the deploy give me, and the deploy continued...
>
> After this, I selected the new SSD RAID1 on my Dell iSCSI box, and the deploy 
> was finally able to copy the HE to the 

[ovirt-devel] Re: VM timezone typo

[Yedidyah Bar David]

On Wed, Sep 1, 2021 at 5:09 AM luwen.zhang  wrote:

>
> Hello team,
>
> We found a minor issue on oVirt 4.4.8 version, it seems like a typo of the
> VM timezone, it should be “GMT+01:00 Central European Standard Time” but on
> 4.4.8 it’s “GMT+01:00 Central European Standard Tim”.
> This lead to Vinchin VM restoration fail at VM creation stage if using VM
> backups from previous oVirt versions.
>

Fix already merged, will be released with 4.4.9:

https://gerrit.ovirt.org/q/I3fce6edf4e3af01f07dec9ae32f5a1a791e9c467

Thanks for the report, anyway :-)

Best regards,
-- 
Didi
___
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/5U5NKWDBXSNTKNS4Y2MNGRAFC3NCSLIV/

[ovirt-devel] Re: OST HE: Engine VM went down due to cpu load

[Yedidyah Bar David]

On Tue, Aug 10, 2021 at 12:05 PM Milan Zamazal  wrote:
>
> Yedidyah Bar David  writes:
>
> > On Tue, Aug 3, 2021 at 10:27 PM Michal Skrivanek <
> > michal.skriva...@redhat.com> wrote:
> >
> >>
> >>
> >> On 3. 8. 2021, at 11:43, Yedidyah Bar David  wrote:
> >>
> >> On Tue, Aug 3, 2021 at 10:05 AM Yedidyah Bar David 
> >> wrote:
> >>
> >>
> >> On Tue, Aug 3, 2021 at 7:50 AM  wrote:
> >>
> >>
> >> Project:
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> >> Build:
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/
> >> Build Number: 2126
> >> Build Status:  Failure
> >> Triggered By: Started by timer
> >>
> >> -
> >> Changes Since Last Success:
> >> -
> >> Changes for Build #2126
> >> [Michal Skrivanek] basic: skipping just the VNC console part of
> >> test_virtual_machines
> >>
> >>
> >>
> >>
> >> -
> >> Failed Tests:
> >> -
> >> 2 tests failed.
> >> FAILED:
> >>  
> >> he-basic-suite-master.test-scenarios.test_012_local_maintenance_sdk.test_local_maintenance
> >>
> >> Error Message:
> >> ovirtsdk4.Error: Failed to read response: [( >> 0xfaf11228>, 7, 'Failed to connect to 192.168.200.99 port 443:
> >> Connection refused')]
> >>
> >>
> >> This looks very similar to the issue we have with dns/dig failures
> >> that cause the engine VM to go down, and it's similar, but different.
> >>
> >> dig didn't fail (it now uses TCP), but something else caused the agent
> >> to stop the engine VM - a combination of high cpu load and low free
> >> memory, after restarting the engine VM as part of test_008.
> >>
> >>
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/artifact/exported-artifacts/test_logs/ost-he-basic-suite-master-host-0/var/log/ovirt-hosted-engine-ha/agent.log
> >> :
> >>
> >>
> >> =
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:46:55,068::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> >> Current state ReinitializeFSM (score: 0)
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:04,089::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> >> Global maintenance detected
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:04,169::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
> >> Success, was notification of state_transition
> >> (ReinitializeFSM-GlobalMaintenance) sent? ignored
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:05,249::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> >> Current state GlobalMaintenance (score: 3400)
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:14,439::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> >> Global maintenance detected
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:25,526::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score)
> >> Penalizing score by 814 due to cpu load
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:25,527::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> >> Current state GlobalMaintenance (score: 2586)
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:25,537::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> >> Global maintenance detected
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:26,029::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> >> Current state GlobalMaintenance (score: 2586)
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:35,050::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> >> Global maintenance detected
> >> MainThread::INFO::2021-08-03
> >>
> >> 06:47:35,576::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_

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

[Yedidyah Bar David]

On Mon, Aug 9, 2021 at 4:29 PM Nir Soffer  wrote:
>
> 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:
> >
> >

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

[Yedidyah Bar David]

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.

OK

>
> 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.x8

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

[Yedidyah Bar David]

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: 

98304
true
4.6
False
0
{}
false
96
96
auto_resume
1628431993.720967

ovirtmgmt


;vdsmdummy;


36001405bc9d94e4419b4b80a2f702e2f
36001405bc9d94e4419b4b80a2f702e2f
False


46fa5761-bb9e-46be-8f1c-35f4b03d0203
20002ad2-4a97-4d2f-b3fc-c103477b5b91
False
7d97ea80-f849-11eb-ac79-5452d501341a
614abd56-4d4f-4412-aa2a-3f7bad2f3a87

1



46fa5761-bb9e-46be-8f1c-35f4b03d0203
20002ad2-4a97-4d2f-b3fc-c103477b5b91
0

/rhev/data-center/mnt/192.168.200.2:_exports_nfs_share1/46fa5761-bb9e-46be-8f1c-35f4b03d0203/images/20002ad2-4a97-4d2f-b3fc-c103477b5b91/1d3f07dc-b481-492f-a2a6-7c46689d82ba.lease

/rhev/data-center/mnt/192.168.200.2:_exports_nfs_share1/46fa5761-bb9e-46be-8f1c-35f4b03d0203/images/20002ad2-4a97-4d2f-b3fc-c103477b5b91/1d3f07dc-b481-492f-a2a6-7c46689d82ba
1d3f07dc-b481-492f-a2a6-7c46689d82ba


46fa5761-bb9e-46be-8f1c-35f4b03d0203
20002ad2-4a97-4d2f-b3fc-c103477b5b91
0

/rhev/data-center/mnt/192.168.200.2:_exports_nfs_share1/46fa5761-bb9e-46be-8f1c-35f4b03d0203/images/20002ad2-4a97-4d2f-b3fc-c103477b5b91/614abd56-4d4f-4412-aa2a-3f7bad2f3a87.lease

/rhev/data-center/mnt/192.168.200.2:_exports_nfs_share1/46fa5761-bb9e-46be-8f1c-35f4b03d0203/images/20002ad2-4a97-4d2f-b3fc-c103477b5b91/614abd56-4d4f-4412-aa2a-3f7bad2f3a87
 

[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!)

[Yedidyah Bar David]

On Mon, Aug 9, 2021 at 1:39 PM Nir Soffer  wrote:
>
> 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.

Thanks.

>
> 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

Makes sense. That's indeed what I was looking for, for VM cpu usage.

>
> > > 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.

In "real", you might refer to two different things:

1. OST is a different environment - has ridiculously little memory/cpu, etc.,
or something else that is not expected or not recommended for a real system.

2. The _flow_ is not real. As in, it's unlikely that a real user will exit
global maintenance so quickly after starting the engine VM, without looking
around a bit more.

I agree with both - and even if it's eventually considered a real bug, I'd
not consider it severe. But just saying "OST is not a real system" is not
something I can completely agree with. We have a balance/tradeoff here between
trying to imitate "real systems" as accurately as possible and between doing
this efficiently/effectively. I do not think there is a deliberate design
choice to make it arbitrarily different from real systems.

Best regards,
-- 
Didi
___
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/BTR3FHQP6LZNTLVOC6PHMBIV5WH27YUG/

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

[Yedidyah Bar David]

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

Any idea?
-- 
Didi
___
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/7UK4BDLCD6PR6DPYL3G6UMMYH3NIEX36/

[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!)

[Yedidyah Bar David]

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.
>
> 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).

Happened again:

https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2132/

Pushed this, for now:

Pushed https://gerrit.ovirt.org/c/ovirt-system-tests/+/116134 he:
test_008_restart_he_vm.py: Wait until host score is good enough

I'd still like to get more input from vdsm people. I don't mind just
opening a bug.
-- 
Didi
___
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/ZIG5TTW7WJCFRSVYYRPPZKA7UCZGPKZK/

[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!)

[Yedidyah Bar David]

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.

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).

[1] 
https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2129/artifact/exported-artifacts/test_logs/ost-he-basic-suite-master-host-0/var/log/vdsm/vdsm.log

[2] grep -i " 05:2[5678].*api. finish getStats.*cpuUser':"

Thanks and best regards,
-- 
Didi
___
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/BUPXKHLOEQN3E5PM6LNFSKAVUYGPYDCF/

[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!)

[Yedidyah Bar David]

On Tue, Aug 3, 2021 at 10:27 PM Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
>
> On 3. 8. 2021, at 11:43, Yedidyah Bar David  wrote:
>
> On Tue, Aug 3, 2021 at 10:05 AM Yedidyah Bar David 
> wrote:
>
>
> On Tue, Aug 3, 2021 at 7:50 AM  wrote:
>
>
> Project:
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> Build:
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/
> Build Number: 2126
> Build Status:  Failure
> Triggered By: Started by timer
>
> -
> Changes Since Last Success:
> -
> Changes for Build #2126
> [Michal Skrivanek] basic: skipping just the VNC console part of
> test_virtual_machines
>
>
>
>
> -
> Failed Tests:
> -
> 2 tests failed.
> FAILED:
>  
> he-basic-suite-master.test-scenarios.test_012_local_maintenance_sdk.test_local_maintenance
>
> Error Message:
> ovirtsdk4.Error: Failed to read response: [( 0xfaf11228>, 7, 'Failed to connect to 192.168.200.99 port 443:
> Connection refused')]
>
>
> This looks very similar to the issue we have with dns/dig failures
> that cause the engine VM to go down, and it's similar, but different.
>
> dig didn't fail (it now uses TCP), but something else caused the agent
> to stop the engine VM - a combination of high cpu load and low free
> memory, after restarting the engine VM as part of test_008.
>
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/artifact/exported-artifacts/test_logs/ost-he-basic-suite-master-host-0/var/log/ovirt-hosted-engine-ha/agent.log
> :
>
>
> =
> MainThread::INFO::2021-08-03
>
> 06:46:55,068::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state ReinitializeFSM (score: 0)
> MainThread::INFO::2021-08-03
>
> 06:47:04,089::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
>
> 06:47:04,169::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
> Success, was notification of state_transition
> (ReinitializeFSM-GlobalMaintenance) sent? ignored
> MainThread::INFO::2021-08-03
>
> 06:47:05,249::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 3400)
> MainThread::INFO::2021-08-03
>
> 06:47:14,439::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
>
> 06:47:25,526::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score)
> Penalizing score by 814 due to cpu load
> MainThread::INFO::2021-08-03
>
> 06:47:25,527::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
>
> 06:47:25,537::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
>
> 06:47:26,029::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
>
> 06:47:35,050::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
>
> 06:47:35,576::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
>
> 06:47:45,597::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
>
> 06:47:46,521::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
>
> 06:47:55,577::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
>
> 06:47:56,559::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
>
> 06:47:56,559::hosted_engine::525::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Best remote h

[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!)

[Yedidyah Bar David]

On Tue, Aug 3, 2021 at 10:05 AM Yedidyah Bar David  wrote:
>
> On Tue, Aug 3, 2021 at 7:50 AM  wrote:
> >
> > Project: 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> > Build: 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/
> > Build Number: 2126
> > Build Status:  Failure
> > Triggered By: Started by timer
> >
> > -
> > Changes Since Last Success:
> > -
> > Changes for Build #2126
> > [Michal Skrivanek] basic: skipping just the VNC console part of 
> > test_virtual_machines
> >
> >
> >
> >
> > -
> > Failed Tests:
> > -
> > 2 tests failed.
> > FAILED:  
> > he-basic-suite-master.test-scenarios.test_012_local_maintenance_sdk.test_local_maintenance
> >
> > Error Message:
> > ovirtsdk4.Error: Failed to read response: [( > 0xfaf11228>, 7, 'Failed to connect to 192.168.200.99 port 443: 
> > Connection refused')]
>
> This looks very similar to the issue we have with dns/dig failures
> that cause the engine VM to go down, and it's similar, but different.
>
> dig didn't fail (it now uses TCP), but something else caused the agent
> to stop the engine VM - a combination of high cpu load and low free
> memory, after restarting the engine VM as part of test_008.
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/artifact/exported-artifacts/test_logs/ost-he-basic-suite-master-host-0/var/log/ovirt-hosted-engine-ha/agent.log
> :
>
> =
> MainThread::INFO::2021-08-03
> 06:46:55,068::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state ReinitializeFSM (score: 0)
> MainThread::INFO::2021-08-03
> 06:47:04,089::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
> 06:47:04,169::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
> Success, was notification of state_transition
> (ReinitializeFSM-GlobalMaintenance) sent? ignored
> MainThread::INFO::2021-08-03
> 06:47:05,249::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 3400)
> MainThread::INFO::2021-08-03
> 06:47:14,439::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
> 06:47:25,526::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score)
> Penalizing score by 814 due to cpu load
> MainThread::INFO::2021-08-03
> 06:47:25,527::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
> 06:47:25,537::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
> 06:47:26,029::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
> 06:47:35,050::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
> 06:47:35,576::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
> 06:47:45,597::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
> 06:47:46,521::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
> 06:47:55,577::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
> Global maintenance detected
> MainThread::INFO::2021-08-03
> 06:47:56,559::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Current state GlobalMaintenance (score: 2586)
> MainThread::INFO::2021-08-03
> 06:47:56,559::hosted_engine::525::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
> Best remote host ost-he-basic-suite-master-host-1 (id: 2, score: 3400)
> MainThread::INFO::2021

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

[Yedidyah Bar David]

On Tue, Aug 3, 2021 at 7:50 AM  wrote:
>
> Project: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> Build: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/
> Build Number: 2126
> Build Status:  Failure
> Triggered By: Started by timer
>
> -
> Changes Since Last Success:
> -
> Changes for Build #2126
> [Michal Skrivanek] basic: skipping just the VNC console part of 
> test_virtual_machines
>
>
>
>
> -
> Failed Tests:
> -
> 2 tests failed.
> FAILED:  
> he-basic-suite-master.test-scenarios.test_012_local_maintenance_sdk.test_local_maintenance
>
> Error Message:
> ovirtsdk4.Error: Failed to read response: [( 0xfaf11228>, 7, 'Failed to connect to 192.168.200.99 port 443: Connection 
> refused')]

This looks very similar to the issue we have with dns/dig failures
that cause the engine VM to go down, and it's similar, but different.

dig didn't fail (it now uses TCP), but something else caused the agent
to stop the engine VM - a combination of high cpu load and low free
memory, after restarting the engine VM as part of test_008.

https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/artifact/exported-artifacts/test_logs/ost-he-basic-suite-master-host-0/var/log/ovirt-hosted-engine-ha/agent.log
:

=
MainThread::INFO::2021-08-03
06:46:55,068::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state ReinitializeFSM (score: 0)
MainThread::INFO::2021-08-03
06:47:04,089::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03
06:47:04,169::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
Success, was notification of state_transition
(ReinitializeFSM-GlobalMaintenance) sent? ignored
MainThread::INFO::2021-08-03
06:47:05,249::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state GlobalMaintenance (score: 3400)
MainThread::INFO::2021-08-03
06:47:14,439::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03
06:47:25,526::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score)
Penalizing score by 814 due to cpu load
MainThread::INFO::2021-08-03
06:47:25,527::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state GlobalMaintenance (score: 2586)
MainThread::INFO::2021-08-03
06:47:25,537::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03
06:47:26,029::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state GlobalMaintenance (score: 2586)
MainThread::INFO::2021-08-03
06:47:35,050::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03
06:47:35,576::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state GlobalMaintenance (score: 2586)
MainThread::INFO::2021-08-03
06:47:45,597::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03
06:47:46,521::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state GlobalMaintenance (score: 2586)
MainThread::INFO::2021-08-03
06:47:55,577::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03
06:47:56,559::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state GlobalMaintenance (score: 2586)
MainThread::INFO::2021-08-03
06:47:56,559::hosted_engine::525::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Best remote host ost-he-basic-suite-master-host-1 (id: 2, score: 3400)
MainThread::INFO::2021-08-03
06:48:05,633::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03
06:48:06,188::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score)
Penalizing score by 820 due to cpu load
MainThread::INFO::2021-08-03
06:48:06,188::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop)
Current state GlobalMaintenance (score: 2580)
MainThread::INFO::2021-08-03
06:48:16,256::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Global maintenance detected
MainThread::INFO::2021-08-03

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

[Yedidyah Bar David]

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.

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 = .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 isinstance(detail, six.string_types):
> if msg:
> msg += ' '
> msg = msg + detail + '.'
>
> class_ = Error
> if response is not None:
> if response.code in [401, 403]:
> class_ = AuthError
> elif response.code == 404:
> class_ = NotFoundError
>
> error = class_(msg)
> error.code = response.code if response else None
> error.fault = fault
> >   raise error
> E   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.
>
> /usr/lib64/python3.6/site-packages/ovirtsdk4/service.py:118: 
> Error___
> Infra mailing list -- in...@ovirt.org
> To 

[ovirt-devel] Re: selenium.common.exceptions.TimeoutException: Message: Clusters menu is not displayed

[Yedidyah Bar David]

On Tue, Jun 29, 2021 at 9:54 AM Lucia Jelinkova  wrote:
>
> Hi Didi,
>
> The issue is intermittent and quite rare actually.

Indeed. After my report yesterday morning I ran OST several more times
and it always passed.

> I tried to improve the way we click the left menu in this patch [1]. Please 
> let me  know in case the patch does not help and you encounter the problem 
> again.
>
> 1: https://gerrit.ovirt.org/#/c/ovirt-system-tests/+/115451/

Thanks a lot!

If it still does not help, do we have enough logs to help understand why?

Also: perhaps if moving to the menu does not open it, we should move
back elsewhere (e.g. to the page center) before retrying? I know that
as a user I do this... (never wrote UI/selenium code, though).

Best regards,
-- 
Didi
___
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/MUZ3CTY4QPU3FHRYDEXMVK3ND3LOSSTK/

[ovirt-devel] Re: selenium.common.exceptions.TimeoutException: Message: Clusters menu is not displayed

[Yedidyah Bar David]

On Wed, Jun 23, 2021 at 2:39 PM Michal Skrivanek
 wrote:
>
>
>
> > On 23. 6. 2021, at 13:29, Yedidyah Bar David  wrote:
> >
> > On Wed, Jun 23, 2021 at 1:03 PM Code Review  wrote:
> >>
> >> From Jenkins CI :
> >>
> >> Jenkins CI has posted comments on this change. ( 
> >> https://gerrit.ovirt.org/c/ovirt-system-tests/+/115191 )
> >>
> >> Change subject: Make the ansible_inventory fixture backend-independent
> >> ..
> >>
> >>
> >> Patch Set 16: Continuous-Integration-1
> >>
> >> Build Failed
> >>
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17451/
> >>  : FAILURE
> >
> > Hi all,
> >
> > Can someone please have a look and decide if this failure is reasonable?
> >
> > The screenshot of the failed "Open cluster list view" does not show
> > anything suspicious at all [1], to me, but not sure how it should
> > otherwise look - e.g. should it include a pointer, which might imply
> > where we tried to move, etc. It timed out 3 minutes after a successful
> > login [2].
>
> it should have opened a Cluster screen, but it looks it’s stuck at the 
> dashboard after login
> we likely have some (timing related perhaps) issues with navigation

Happened a few more times:

https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/1261/

https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/1273/

Best regards,

>
> >
> > If it's not supposed to include a pointer, perhaps we should try to
> > make selenium do include a pointer in the screenshots - I have a
> > feeling this can help debug other UI issues. But I don't know this
> > code at all...
> >
> > Thanks and best regards,
> >
> > [1] 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17451/artifact/check-patch.basic_suite_master.el8.x86_64/ui_tests_artifacts/20210623_100213_302883_firefox_test_clusters_failed.png
> >
> > [2] 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17451/artifact/check-patch.basic_suite_master.el8.x86_64/ui_tests_artifacts/20210623_095906_004756_firefox_test_login_success.png
> >
> >>
> >>
> >> --
> >> To view, visit https://gerrit.ovirt.org/c/ovirt-system-tests/+/115191
> >> To unsubscribe, or for help writing mail filters, visit 
> >> https://gerrit.ovirt.org/settings
> >>
> >> Gerrit-Project: ovirt-system-tests
> >> Gerrit-Branch: master
> >> Gerrit-Change-Id: Id07012f8fc3a972a3b62d32f2271d5747514e13a
> >> Gerrit-Change-Number: 115191
> >> Gerrit-PatchSet: 16
> >> Gerrit-Owner: Yedidyah Bar David 
> >> Gerrit-Reviewer: Andrej Cernek 
> >> Gerrit-Reviewer: Anton Marchukov 
> >> Gerrit-Reviewer: Dafna Ron 
> >> Gerrit-Reviewer: Dusan Fodor 
> >> Gerrit-Reviewer: Gal Ben Haim 
> >> Gerrit-Reviewer: Galit Rosenthal 
> >> Gerrit-Reviewer: Jenkins CI 
> >> Gerrit-Reviewer: Marcin Sobczyk 
> >> Gerrit-Reviewer: Name of user not set #1001916
> >> Gerrit-Reviewer: Yedidyah Bar David 
> >> Gerrit-Comment-Date: Wed, 23 Jun 2021 10:03:15 +
> >> Gerrit-HasComments: No
> >> Gerrit-Has-Labels: Yes
> >> Gerrit-MessageType: comment
> >>
> >
> >
> > --
> > Didi
> > ___
> > 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/EFZVD6IQLBXGOLUCSQ7N7NCZ6EKVVA4P/
>


--
Didi
___
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/7ETT4HLRIWXSCPSDWTFULIIAWLMGPZZS/

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

[Yedidyah Bar David]

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'

Best regards,
-- 
Didi
___
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/UIZOOEASMPUE3VWDNNPN23VI64YJ5EIA/

[ovirt-devel] Re: basic OST: Error initializing source docker, unauthorized: incorrect username or password

[Yedidyah Bar David]

On Wed, Jun 23, 2021 at 10:29 AM Marcin Sobczyk  wrote:
>
>
>
> On 6/23/21 7:31 AM, Yedidyah Bar David wrote:
> > Hi all,
> >
> > On Mon, Jun 21, 2021 at 8:55 PM  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/1235/
> > This is a week-old build, but some (but not all) of the check-patch
> > OST runs I did yesterday failed the same way, e.g. [1][2]:
> >
> > ==
> > failed on setup with "ost_utils.shell.ShellError: Command failed with
> > rc=125. Stdout:
> >
> > Stderr:
> > Trying to pull docker.io/selenium/hub:3.141.59-20210422...
> >unable to retrieve auth token: invalid username/password:
> > unauthorized: incorrect username or password
> > Error: 1 error occurred:
> > * Error initializing source docker://selenium/hub:3.141.59-20210422:
> > unable to retrieve auth token: invalid username/password:
> > unauthorized: incorrect username or password"
> > ==
> >
> > Is this a known issue? Perhaps related to docker's rate-limiting?
> Also stumbled upon this some time ago, but it stopped reproducing somehow.
> There's a bug filed for this - CPDEVOPS-176.

Link, please? This one says "Something's gone wrong":

https://ovirt-jira.atlassian.net/browse/CPDEVOPS-176

This now happened again:

https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17456/

Best regards,

>
> Regards, Marcin
>
> >
> > [1] 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17434/
> >
> > [2] 
> > https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17434/testReport/junit/basic-suite-master.test-scenarios/test_100_basic_ui_sanity/Invoking_jobs___check_patch_basic_suite_master_el8_x86_64___test_secure_connection_should_fail_without_root_ca_firefox_/
> >
> > Best regards,
>


-- 
Didi
___
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/MAEPTNUNWJQ6FK5BYZ37XOCQ6YY2PMJ7/

[ovirt-devel] selenium.common.exceptions.TimeoutException: Message: Clusters menu is not displayed

[Yedidyah Bar David]

On Wed, Jun 23, 2021 at 1:03 PM Code Review  wrote:
>
> From Jenkins CI :
>
> Jenkins CI has posted comments on this change. ( 
> https://gerrit.ovirt.org/c/ovirt-system-tests/+/115191 )
>
> Change subject: Make the ansible_inventory fixture backend-independent
> ..
>
>
> Patch Set 16: Continuous-Integration-1
>
> Build Failed
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17451/ 
> : FAILURE

Hi all,

Can someone please have a look and decide if this failure is reasonable?

The screenshot of the failed "Open cluster list view" does not show
anything suspicious at all [1], to me, but not sure how it should
otherwise look - e.g. should it include a pointer, which might imply
where we tried to move, etc. It timed out 3 minutes after a successful
login [2].

If it's not supposed to include a pointer, perhaps we should try to
make selenium do include a pointer in the screenshots - I have a
feeling this can help debug other UI issues. But I don't know this
code at all...

Thanks and best regards,

[1] 
https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17451/artifact/check-patch.basic_suite_master.el8.x86_64/ui_tests_artifacts/20210623_100213_302883_firefox_test_clusters_failed.png

[2] 
https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17451/artifact/check-patch.basic_suite_master.el8.x86_64/ui_tests_artifacts/20210623_095906_004756_firefox_test_login_success.png

>
>
> --
> To view, visit https://gerrit.ovirt.org/c/ovirt-system-tests/+/115191
> To unsubscribe, or for help writing mail filters, visit 
> https://gerrit.ovirt.org/settings
>
> Gerrit-Project: ovirt-system-tests
> Gerrit-Branch: master
> Gerrit-Change-Id: Id07012f8fc3a972a3b62d32f2271d5747514e13a
> Gerrit-Change-Number: 115191
> Gerrit-PatchSet: 16
> Gerrit-Owner: Yedidyah Bar David 
> Gerrit-Reviewer: Andrej Cernek 
> Gerrit-Reviewer: Anton Marchukov 
> Gerrit-Reviewer: Dafna Ron 
> Gerrit-Reviewer: Dusan Fodor 
> Gerrit-Reviewer: Gal Ben Haim 
> Gerrit-Reviewer: Galit Rosenthal 
> Gerrit-Reviewer: Jenkins CI 
> Gerrit-Reviewer: Marcin Sobczyk 
> Gerrit-Reviewer: Name of user not set #1001916
> Gerrit-Reviewer: Yedidyah Bar David 
> Gerrit-Comment-Date: Wed, 23 Jun 2021 10:03:15 +
> Gerrit-HasComments: No
> Gerrit-Has-Labels: Yes
> Gerrit-MessageType: comment
>


-- 
Didi
___
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/EFZVD6IQLBXGOLUCSQ7N7NCZ6EKVVA4P/

[ovirt-devel] Re: ansible OST: Failed to hot-plug disk

[Yedidyah Bar David]

On Wed, Jun 23, 2021 at 8:15 AM Yedidyah Bar David  wrote:
>
> Hi all,
>
> Please see [1], failed twice so far:
>
> "msg": "Fault reason is \"Operation Failed\". Fault detail is
> \"[Failed to hot-plug disk]\". HTTP response code is 400."

vdsm.log has:

libvirt.libvirtError: unsupported configuration: IOThreads only
available for virtio pci and virtio ccw disk

Seems like [1], caused by reverting the patches to require libvirt <
7.4. Do we have a workaround? Or just wait for a fix?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1974096

>
> Thanks and best regards,
>
> [1] 
> https://jenkins.ovirt.org/job/ovirt-system-tests_ansible-suite-master/1972/
> --
> Didi



-- 
Didi
___
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/FB27JAY6S35KH2XQ4MCLG4CK23R5IEIU/

[ovirt-devel] basic OST: Error initializing source docker, unauthorized: incorrect username or password

[Yedidyah Bar David]

Hi all,

On Mon, Jun 21, 2021 at 8:55 PM  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/1235/

This is a week-old build, but some (but not all) of the check-patch
OST runs I did yesterday failed the same way, e.g. [1][2]:

==
failed on setup with "ost_utils.shell.ShellError: Command failed with
rc=125. Stdout:

Stderr:
Trying to pull docker.io/selenium/hub:3.141.59-20210422...
  unable to retrieve auth token: invalid username/password:
unauthorized: incorrect username or password
Error: 1 error occurred:
* Error initializing source docker://selenium/hub:3.141.59-20210422:
unable to retrieve auth token: invalid username/password:
unauthorized: incorrect username or password"
==

Is this a known issue? Perhaps related to docker's rate-limiting?

[1] https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17434/

[2] 
https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17434/testReport/junit/basic-suite-master.test-scenarios/test_100_basic_ui_sanity/Invoking_jobs___check_patch_basic_suite_master_el8_x86_64___test_secure_connection_should_fail_without_root_ca_firefox_/

Best regards,
-- 
Didi
___
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/GKT3I6N3YLMT6QWHPBL4RVCDU4GHJO7Z/

[ovirt-devel] ansible OST: Failed to hot-plug disk

[Yedidyah Bar David]

Hi all,

Please see [1], failed twice so far:

"msg": "Fault reason is \"Operation Failed\". Fault detail is
\"[Failed to hot-plug disk]\". HTTP response code is 400."

Thanks and best regards,

[1] https://jenkins.ovirt.org/job/ovirt-system-tests_ansible-suite-master/1972/
-- 
Didi
___
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/VD4YOQBA4M5BBJUSCULQFYIS7RR2NEEZ/

[ovirt-devel] Re: Gerrit hook adds unrelated patches to bugs

[Yedidyah Bar David]

On Mon, Jun 21, 2021 at 9:58 PM Eyal Shenitzky  wrote:
>
>
> +Dusan Fodor
>
> On Mon, 21 Jun 2021 at 13:32, Nir Soffer  wrote:
>>
>> Gerrit hook is wrongly looking for https://bugzilla.redhat.com/ URLs
>> in the commit message, and adding the patch to the bug.
>>
>> Example patch:
>> https://gerrit.ovirt.org/c/vdsm/+/115339
>>
>> I had to clean up the bug after the broken hook (see screenshot).
>>
>> The hook should really look only in the single URL in (one or more)
>> Bug-Url headers:
>>
>> Bug-Url: https://bugzilla.redhat.com/
>>
>> I reported this years ago (I think for Related-To:), and I remember we had
>> a patch fixing this issue, but for some reason it was lost.
>>
>> Nir

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

Best regards,
-- 
Didi
___
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/6JPPSC5FDZFE4HK577MHT3WXITFOKEI3/

[ovirt-devel] Re: hc-basic-suite-master fails due to missing glusterfs firewalld services

[Yedidyah Bar David]

On Thu, Jun 17, 2021 at 6:27 PM Marcin Sobczyk  wrote:
>
>
>
> On 6/17/21 1:44 PM, Yedidyah Bar David wrote:
> > On Wed, Jun 16, 2021 at 1:23 PM Yedidyah Bar David  wrote:
> >> Hi,
> >>
> >> I now tried running locally hc-basic-suite-master with a patched OST,
> >> and it failed due to $subject. I checked and see that this also
> >> happened on CI, e.g. [1], before it started failing to to an unrelated
> >> reason later:
> >>
> >> E   TASK [gluster.infra/roles/firewall_config : Add/Delete
> >> services to firewalld rules] ***
> >> E   failed: [lago-hc-basic-suite-master-host-0]
> >> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> >> "item": "glusterfs", "msg": "ERROR: Exception caught:
> >> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> >> not among existing services Permanent and Non-Permanent(immediate)
> >> operation, Services are defined by port/tcp relationship and named as
> >> they are in /etc/services (on most systems)"}
> >> E   failed: [lago-hc-basic-suite-master-host-2]
> >> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> >> "item": "glusterfs", "msg": "ERROR: Exception caught:
> >> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> >> not among existing services Permanent and Non-Permanent(immediate)
> >> operation, Services are defined by port/tcp relationship and named as
> >> they are in /etc/services (on most systems)"}
> >> E   failed: [lago-hc-basic-suite-master-host-1]
> >> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> >> "item": "glusterfs", "msg": "ERROR: Exception caught:
> >> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> >> not among existing services Permanent and Non-Permanent(immediate)
> >> operation, Services are defined by port/tcp relationship and named as
> >> they are in /etc/services (on most systems)"}
> >>
> >> This seems similar to [2], and indeed I can't see the package
> >> 'glusterfs-server' installed locally on host-0. Any idea?
> > I think I understand:
> >
> > It seems like the deployment of hc relied on the order of running the deploy
> > scripts as written in lagoinitfile. With the new deploy code, all of them 
> > run
> > in parallel. Does this make sense?
> The scripts run in parallel as in "on all VMs at the same time", but
> sequentially
> as in "one script at a time on each VM" - this is the same behavior we
> had with lago deployment.

Well, I do not think it works as intended, then. When running locally,
I logged into host-0, and after it failed, I had:

# dnf history
ID | Command line

   | Date and time| Action(s)  | Altered
--
 4 | install -y --nogpgcheck ansible gluster-ansible-roles
ovirt-hosted-engine-setup ovirt-ansible-hosted-engine-setup
ovirt-ansible-reposit | 2021-06-17 11:54 | I, U   |8
 3 | -y --nogpgcheck install ovirt-host python3-coverage
vdsm-hook-vhostmd
 | 2021-06-08 02:15 | Install|  493 EE
 2 | install -y dnf-utils
https://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
| 2021-06-08 02:14 |
Install|1
 1 |

   | 2021-06-08 02:06 | Install|  511 EE

Meaning, it already ran setup_first_host.sh (and failed there), but
didn't run hc_setup_host.sh, although it appears before it.

If you check [1], which is a build that failed due to this reason
(unlike the later ones), you see there:

-- Captured log setup --
2021-06-07 01:58:38+,594 INFO
[ost_utils.pytest.fixtures.deployment] Waiting for SSH on the VMs
(deployment:40)
2021-06-07 01:59:11+,947 INFO
[ost_utils.deployment_utils.package_mgmt] oVirt packages used on VMs:
(package_mgmt:133)
2021-06-07 01:59:11+,948 INFO
[ost_utils.deployment_utils.package_mgmt]
vdsm-4.40.70.2-1.git34cdc8884.el8.x86_64 (package_mgmt:135)
2021-06-07 01:59:11+,950 INFO
[ost_utils.deployment_utils.scripts] Running
/home/jenkins/workspace/ovirt-system-tests_hc-basic-suite-master/ovirt-system-tests/common/deploy-scripts/setup_host.sh
on lago-hc-basic-suite-master-host-1 (

[ovirt-devel] test_hotplug_memory fails basic and he-basic

[Yedidyah Bar David]

Hi all,

On Sun, Jun 20, 2021 at 7:18 AM  wrote:
>
> Project: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> Build: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2060/
> Build Number: 2060

basic-suite-master started failing on test_hotplug_memory at:

https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/1247/

1246 failed on a later test (due to some other (temporary) reason?),
all other runs since failed on test_hotplug_memory.

Didn't try to bisect engine/vdsm.

On an OST check-patch run from this afternoon, basic-suite did pass,
so it's not always failing:

https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/17364/

Any idea?

Thanks and best regards,
--
Didi
___
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/XDFBOSXCNLNMA5VVDQ45T74FGGHJVMDP/

[ovirt-devel] hc-basic-suite-master fails due to missing glusterfs firewalld services

[Yedidyah Bar David]

Hi,

I now tried running locally hc-basic-suite-master with a patched OST,
and it failed due to $subject. I checked and see that this also
happened on CI, e.g. [1], before it started failing to to an unrelated
reason later:

E   TASK [gluster.infra/roles/firewall_config : Add/Delete
services to firewalld rules] ***
E   failed: [lago-hc-basic-suite-master-host-0]
(item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
"item": "glusterfs", "msg": "ERROR: Exception caught:
org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
not among existing services Permanent and Non-Permanent(immediate)
operation, Services are defined by port/tcp relationship and named as
they are in /etc/services (on most systems)"}
E   failed: [lago-hc-basic-suite-master-host-2]
(item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
"item": "glusterfs", "msg": "ERROR: Exception caught:
org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
not among existing services Permanent and Non-Permanent(immediate)
operation, Services are defined by port/tcp relationship and named as
they are in /etc/services (on most systems)"}
E   failed: [lago-hc-basic-suite-master-host-1]
(item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
"item": "glusterfs", "msg": "ERROR: Exception caught:
org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
not among existing services Permanent and Non-Permanent(immediate)
operation, Services are defined by port/tcp relationship and named as
they are in /etc/services (on most systems)"}

This seems similar to [2], and indeed I can't see the package
'glusterfs-server' installed locally on host-0. Any idea?

Thanks and best regards,

[1] https://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/2088/

[2] https://github.com/oVirt/ovirt-ansible/issues/124
-- 
Didi
___
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/TDGYVCAECQMP4QOARXZJG5EVSLQQTIOY/

[ovirt-devel] basic-suite-master is broken

[Yedidyah Bar David]

Failed last 5 runs:

https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/

Known issue?
-- 
Didi
___
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/6TGEYYGCBFNPPRFRY7NGLKEMMNOWB4CO/

[ovirt-devel] Re: hc-basic-suite-master fails due to missing glusterfs firewalld services

[Yedidyah Bar David]

On Wed, Jun 16, 2021 at 1:23 PM Yedidyah Bar David  wrote:
>
> Hi,
>
> I now tried running locally hc-basic-suite-master with a patched OST,
> and it failed due to $subject. I checked and see that this also
> happened on CI, e.g. [1], before it started failing to to an unrelated
> reason later:
>
> E   TASK [gluster.infra/roles/firewall_config : Add/Delete
> services to firewalld rules] ***
> E   failed: [lago-hc-basic-suite-master-host-0]
> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> "item": "glusterfs", "msg": "ERROR: Exception caught:
> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> not among existing services Permanent and Non-Permanent(immediate)
> operation, Services are defined by port/tcp relationship and named as
> they are in /etc/services (on most systems)"}
> E   failed: [lago-hc-basic-suite-master-host-2]
> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> "item": "glusterfs", "msg": "ERROR: Exception caught:
> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> not among existing services Permanent and Non-Permanent(immediate)
> operation, Services are defined by port/tcp relationship and named as
> they are in /etc/services (on most systems)"}
> E   failed: [lago-hc-basic-suite-master-host-1]
> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> "item": "glusterfs", "msg": "ERROR: Exception caught:
> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> not among existing services Permanent and Non-Permanent(immediate)
> operation, Services are defined by port/tcp relationship and named as
> they are in /etc/services (on most systems)"}
>
> This seems similar to [2], and indeed I can't see the package
> 'glusterfs-server' installed locally on host-0. Any idea?

I think I understand:

It seems like the deployment of hc relied on the order of running the deploy
scripts as written in lagoinitfile. With the new deploy code, all of them run
in parallel. Does this make sense?


>
> Thanks and best regards,
>
> [1] 
> https://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/2088/
>
> [2] https://github.com/oVirt/ovirt-ansible/issues/124
> --
> Didi



--
Didi
___
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/HQ37ENFRGYJK4H3INGAAR5FYWK33WAH4/

[ovirt-devel] Re: hc-basic-suite-master fails due to missing glusterfs firewalld services

[Yedidyah Bar David]

On Fri, Jun 18, 2021 at 10:18 AM Marcin Sobczyk  wrote:
>
>
>
> On 6/17/21 6:59 PM, Yedidyah Bar David wrote:
> > On Thu, Jun 17, 2021 at 6:27 PM Marcin Sobczyk  wrote:
> >>
> >>
> >> On 6/17/21 1:44 PM, Yedidyah Bar David wrote:
> >>> On Wed, Jun 16, 2021 at 1:23 PM Yedidyah Bar David  
> >>> wrote:
> >>>> Hi,
> >>>>
> >>>> I now tried running locally hc-basic-suite-master with a patched OST,
> >>>> and it failed due to $subject. I checked and see that this also
> >>>> happened on CI, e.g. [1], before it started failing to to an unrelated
> >>>> reason later:
> >>>>
> >>>> E   TASK [gluster.infra/roles/firewall_config : Add/Delete
> >>>> services to firewalld rules] ***
> >>>> E   failed: [lago-hc-basic-suite-master-host-0]
> >>>> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> >>>> "item": "glusterfs", "msg": "ERROR: Exception caught:
> >>>> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> >>>> not among existing services Permanent and Non-Permanent(immediate)
> >>>> operation, Services are defined by port/tcp relationship and named as
> >>>> they are in /etc/services (on most systems)"}
> >>>> E   failed: [lago-hc-basic-suite-master-host-2]
> >>>> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> >>>> "item": "glusterfs", "msg": "ERROR: Exception caught:
> >>>> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> >>>> not among existing services Permanent and Non-Permanent(immediate)
> >>>> operation, Services are defined by port/tcp relationship and named as
> >>>> they are in /etc/services (on most systems)"}
> >>>> E   failed: [lago-hc-basic-suite-master-host-1]
> >>>> (item=glusterfs) => {"ansible_loop_var": "item", "changed": false,
> >>>> "item": "glusterfs", "msg": "ERROR: Exception caught:
> >>>> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
> >>>> not among existing services Permanent and Non-Permanent(immediate)
> >>>> operation, Services are defined by port/tcp relationship and named as
> >>>> they are in /etc/services (on most systems)"}
> >>>>
> >>>> This seems similar to [2], and indeed I can't see the package
> >>>> 'glusterfs-server' installed locally on host-0. Any idea?
> >>> I think I understand:
> >>>
> >>> It seems like the deployment of hc relied on the order of running the 
> >>> deploy
> >>> scripts as written in lagoinitfile. With the new deploy code, all of them 
> >>> run
> >>> in parallel. Does this make sense?
> >> The scripts run in parallel as in "on all VMs at the same time", but
> >> sequentially
> >> as in "one script at a time on each VM" - this is the same behavior we
> >> had with lago deployment.
> > Well, I do not think it works as intended, then. When running locally,
> > I logged into host-0, and after it failed, I had:
> >
> > # dnf history
> > ID | Command line
> >
> > | Date and time| Action(s)  | Altered
> > --
> >   4 | install -y --nogpgcheck ansible gluster-ansible-roles
> > ovirt-hosted-engine-setup ovirt-ansible-hosted-engine-setup
> > ovirt-ansible-reposit | 2021-06-17 11:54 | I, U   |8
> >   3 | -y --nogpgcheck install ovirt-host python3-coverage
> > vdsm-hook-vhostmd
> >   | 2021-06-08 02:15 | Install|  493 EE
> >   2 | install -y dnf-utils
> > https://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
> >  | 2021-06-08 02:14 |
> > Install|1
> >   1 |
> >
> > | 2021-06-08 02:06 | Install|  511 EE
> >
> > Meaning, it already ran setup_first_host.sh (and failed there), but
> > didn't run hc_setup_host.sh, although it appears before it.
> >
> &g

[ovirt-devel] importing fixtures in ovirt-system-tests

[Yedidyah Bar David]

Hi all,

We have several different styles of where/how to import fixtures in
ovirt-system-tests:

- import directly inside the test code
- import in conftest.py
- import in fixtures modules
- For all of above, both 'import *' and importing specific fixtures

I think we should try to agree on a specific style and then follow it.

One drawback of importing directly in test/fixtures code is that it's
then impossible to override them in conftest.py.

A drawback of importing '*' and/or doing this in conftest.py is that
you might inadvertently import more than you want, or this might
happen eventually (after more stuff are added), that this makes it
harder to find what uses what, and that it risks unintended collisions
in names - as opposed to intended overrides.

A related issue is having to update many places if you add/change something.

If there is some kind of "best practices" document somewhere that
people are happy with, perhaps we should follow it. Otherwise, we
should come up with our own.

Personally I think I'd like to have a single file with all the
imports, of specific fixtures (not '*'), and import this file from
conftest.py of all the suites. Didn't actually try this and no idea
what complications it might bring.

Comments/ideas/opinions/decisions are welcome :-)

Best regards,
-- 
Didi
___
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/VAOD5Q7WU2FC66KF5GS3KXWPLCZ2KYS6/

[ovirt-devel] Re: engine-setup fail with: ValueError: invalid literal for int() with base 10: '8MB'

[Yedidyah Bar David]

On Fri, Jun 4, 2021 at 12:15 AM Nir Soffer  wrote:
>
> I tried to install engine from rpms on my development host.
> This host was running engine development setup (using make install-dev)
> for a couple of months.
>
> Building the rpms was successful, but engine-setup failed:
>
> 2021-06-03 23:37:41,370+0300 DEBUG otopi.context
> context._executeMethod:145 method exception
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132,
> in _executeMethod
> method['method']()
>   File 
> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/provisioning/postgres.py",
> line 192, in _
> misc
> self._provisioning.provision()
>   File 
> "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/postgres.py",
> line 541, in provision
> transaction=localtransaction,
>   File 
> "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/postgres.py",
> line 276, in _updatePostgresConf
> needUpdate, content = dbovirtutils.getUpdatedPGConf(content)
>   File 
> "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
> line 1163, in getUpdatedPGConf
> expected=item['expected']
>   File 
> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/configuration.py",
> line 136, in  a>
> int(current) >= int(expected)
> ValueError: invalid literal for int() with base 10: '8MB'
> 2021-06-03 23:37:41,372+0300 ERROR otopi.context
> context._executeMethod:154 Failed to execute stage 'Misc
> configuration': invalid literal for int() with base 10: '8MB'
>
> 8MB sounds familiar - this value was recommended in README.adoc:
>
> work_mem = 8MB
>
> So I configured postgresql.conf like this.
>
> I edited /var/lib/pgsql/data/postgresql.conf and change the value to:
>
> work_mem = 8388608
>
> After that engine-setup succeeded.
>
> Looks like a bug, our verification does not support the valid configuration 
> that
> we recommend.

Filed https://bugzilla.redhat.com/show_bug.cgi?id=1968146 . Thanks for
the report.

Best regards,
-- 
Didi
___
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/M672GUPIN2GGDN4PDG3V34CM5DEP4H4F/

[ovirt-devel] Re: OST HE fails due to empty CPU type (was: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 2038 - Still Failing!)

[Yedidyah Bar David]

On Tue, Jun 1, 2021 at 11:33 AM Marcin Sobczyk  wrote:
>
> Hi,
>
>
> On 6/1/21 8:25 AM, Yedidyah Bar David wrote:
> >   Hi all,
> >
> > On Tue, Jun 1, 2021 at 5:23 AM  wrote:
> >> Project: 
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> >> Build: 
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2038/
> > This has been failing for a week now. Not sure about the root cause.
> There's a bug for this [1]
> Yesterday I pushed a workaround to ost-images for this problem [2], so
> if you update images you should be good.

Can't tell if CI updates them, we do not log their version AFAICT.

It still fails, though. 2039 failed IIRC for the same reason, 2040
failed due to some other weird reason (seems to have failed to start
host-0), and so I manually rebuilt it and it failed again on empty
cpu type.

rpm log (on the host) does show that edk2-ovmf was installed, and based
on the timestamps of all lines from beginning to edk2-ovmf it seems to
have been part of initial creation, not OST updates/installs:

https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2041/artifact/exported-artifacts/test_logs/he-basic-suite-master/lago-he-basic-suite-master-host-0/_var_log/dnf.rpm.log

Best regards,

>
> Regards, Marcin
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1961558
> [2] https://gerrit.ovirt.org/#/c/ost-images/+/115002/
>
> >  From HE deploy code POV:
> >
> > https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2038/artifact/exported-artifacts/test_logs/he-basic-suite-master/lago-he-basic-suite-master-host-0/_var_log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-ansible-create_target_vm-20210601042210-i8r7ks.log
> > :
> >
> > 2021-06-01 04:22:22,497+0200 DEBUG var changed: host "localhost" var
> > "cluster_facts" type "" value: "{
> >  "changed": false,
> >  "failed": false,
> >  "ovirt_clusters": [
> >  {
> >  "affinity_groups": [],
> >  "ballooning_enabled": true,
> >  "comment": "",
> >  "cpu": {
> >  "architecture": "undefined",
> >  "type": ""
> >  },
> >
> > Meaning, the engine says that cluster Default's cpu type is "". The
> > code uses this value as-is, and a few tasks later fails in:
> >
> > 2021-06-01 04:22:26,815+0200 DEBUG ansible on_any args TASK:
> > ovirt.ovirt.hosted_engine_setup : Convert CPU model name  kwargs
> > is_conditional:False
> > 2021-06-01 04:22:26,816+0200 DEBUG ansible on_any args localhost TASK:
> > ovirt.ovirt.hosted_engine_setup : Convert CPU model name  kwargs
> > 2021-06-01 04:22:26,974+0200 DEBUG var changed: host "localhost" var
> > "ansible_play_hosts" type "" value: "[]"
> > 2021-06-01 04:22:26,974+0200 DEBUG var changed: host "localhost" var
> > "ansible_play_batch" type "" value: "[]"
> > 2021-06-01 04:22:26,974+0200 DEBUG var changed: host "localhost" var
> > "play_hosts" type "" value: "[]"
> > 2021-06-01 04:22:26,975+0200 ERROR ansible failed {
> >  "ansible_host": "localhost",
> >  "ansible_playbook":
> > "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml",
> >  "ansible_result": {
> >  "_ansible_no_log": false,
> >  "msg": "The task includes an option with an undefined
> > variable. The error was: 'dict object' has no attribute ''\n\nThe
> > error appears to be in
> > '/usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
> > line 64, column 5, but may\nbe elsewhere in the file depending on the
> > exact syntax problem.\n\nThe offending line appears to be:\n\n  {{
> > server_cpu_list['ovirt_system_option']['values'][0]['value'].split(';
> > ')|list|difference(['']) }}\n  - name: Convert CPU model name\n^
> > here\n"
> >  },
> >  "ansible_task": "Convert CPU model name",
> >  "ansible_type": "task",
> >  "status": "FAILED",
> >  "task_duration": 0
> > }
> >
> > Any ideas?
> >
> > Thanks and best regards,
>


-- 
Didi
___
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/XW6CMXCP3XQMUDSRTFML6SLXRO6LU22T/

[ovirt-devel] OST HE fails due to empty CPU type (was: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 2038 - Still Failing!)

[Yedidyah Bar David]

 Hi all,

On Tue, Jun 1, 2021 at 5:23 AM  wrote:
>
> Project: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> Build: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2038/

This has been failing for a week now. Not sure about the root cause.
From HE deploy code POV:

https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2038/artifact/exported-artifacts/test_logs/he-basic-suite-master/lago-he-basic-suite-master-host-0/_var_log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-ansible-create_target_vm-20210601042210-i8r7ks.log
:

2021-06-01 04:22:22,497+0200 DEBUG var changed: host "localhost" var
"cluster_facts" type "" value: "{
"changed": false,
"failed": false,
"ovirt_clusters": [
{
"affinity_groups": [],
"ballooning_enabled": true,
"comment": "",
"cpu": {
"architecture": "undefined",
"type": ""
},

Meaning, the engine says that cluster Default's cpu type is "". The
code uses this value as-is, and a few tasks later fails in:

2021-06-01 04:22:26,815+0200 DEBUG ansible on_any args TASK:
ovirt.ovirt.hosted_engine_setup : Convert CPU model name  kwargs
is_conditional:False
2021-06-01 04:22:26,816+0200 DEBUG ansible on_any args localhost TASK:
ovirt.ovirt.hosted_engine_setup : Convert CPU model name  kwargs
2021-06-01 04:22:26,974+0200 DEBUG var changed: host "localhost" var
"ansible_play_hosts" type "" value: "[]"
2021-06-01 04:22:26,974+0200 DEBUG var changed: host "localhost" var
"ansible_play_batch" type "" value: "[]"
2021-06-01 04:22:26,974+0200 DEBUG var changed: host "localhost" var
"play_hosts" type "" value: "[]"
2021-06-01 04:22:26,975+0200 ERROR ansible failed {
"ansible_host": "localhost",
"ansible_playbook":
"/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml",
"ansible_result": {
"_ansible_no_log": false,
"msg": "The task includes an option with an undefined
variable. The error was: 'dict object' has no attribute ''\n\nThe
error appears to be in
'/usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
line 64, column 5, but may\nbe elsewhere in the file depending on the
exact syntax problem.\n\nThe offending line appears to be:\n\n  {{
server_cpu_list['ovirt_system_option']['values'][0]['value'].split(';
')|list|difference(['']) }}\n  - name: Convert CPU model name\n^
here\n"
},
"ansible_task": "Convert CPU model name",
"ansible_type": "task",
"status": "FAILED",
"task_duration": 0
}

Any ideas?

Thanks and best regards,
-- 
Didi
___
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/PGBNPWBGT6KFPIBBUPD3SCE4O4XXSCGH/

[ovirt-devel] openvswitch conflict (was: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 2029 - Still Failing!)

[Yedidyah Bar David]

On Wed, May 26, 2021 at 1:14 PM  wrote:
>
> Project: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> Build: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2029/

https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2029/artifact/exported-artifacts/test_logs/he-basic-suite-master/lago-he-basic-suite-master-host-0/_var_log/ovirt-hosted-engine-setup/engine-logs-2021-05-26T09%3A40%3A41Z/log/ovirt-engine/host-deploy/ovirt-host-deploy-ansible-20210526115220-lago-he-basic-suite-master-host-0.lago.local-498bfa09.log
:

2021-05-26 11:53:53 CEST - TASK [ovirt-provider-ovn-driver : Install
ovs] *
2021-05-26 11:53:56 CEST - fatal:
[lago-he-basic-suite-master-host-0.lago.local]: FAILED! => {"changed":
false, "failures": [], "msg": "Unknown Error occured: Transaction test
error:\n  file /usr/bin/ovs-appctl from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file /usr/bin/ovs-dpctl from
install of openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from
package openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/bin/ovs-ofctl from install of openvswitch-2.12.0-1.1.el8.x86_64
conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file /usr/bin/ovs-pki from
install of openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from
package openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/bin/ovs-vsctl from install of openvswitch-2.12.0-1.1.el8.x86_64
conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file /usr/bin/ovsdb-client
from install of openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file
from package openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/bin/ovsdb-tool from install of openvswitch-2.12.0-1.1.el8.x86_64
conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file /usr/bin/vtep-ctl from
install of openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from
package openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/sbin/ovs-vswitchd from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file /usr/sbin/ovsdb-server
from install of openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file
from package openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man1/ovsdb-client.1.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man1/ovsdb-server.1.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man1/ovsdb-tool.1.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man5/ovs-vswitchd.conf.db.5.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man5/ovsdb-server.5.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man5/ovsdb.5.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man5/vtep.5.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man7/ovs-actions.7.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man7/ovs-fields.7.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man7/ovsdb-server.7.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man7/ovsdb.7.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man8/ovs-appctl.8.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man8/ovs-dpctl.8.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man8/ovs-ofctl.8.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man8/ovs-pki.8.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package
openvswitch2.11-2.11.3-87.el8s.x86_64\n  file
/usr/share/man/man8/ovs-vsctl.8.gz from install of
openvswitch-2.12.0-1.1.el8.x86_64 conflicts with file from package

[ovirt-devel] OST ansible inventory rework

[Yedidyah Bar David]

Hi all,

As part of the discussion around [1], we talked about changing the way
we create and use the ansible inventory.

I am now in the middle of doing something about this. It turned our
far more complex and possibly less elegant than
expected/hoped/intended.

I'd like to get a high-level review for my WIP [2]. It's not tested
and not ready for review. But if people think this is going in the
correct direction, I'll continue. Otherwise, I'll give up - and then
we have to decide how to continue otherwise. Parts of this can most
likely be done more nicely, other parts should probably be completely
replaced/removed/redone. We should probably also make some hard
decisions, which I am frankly not sure we can make without having more
concrete ideas about what other backends we want and how they would
look like. So for now I ignored all this and simply did a POC.

So, WDYT?

Thanks and best regards,

[1] https://gerrit.ovirt.org/c/ovirt-system-tests/+/114653

[2] https://github.com/didib/ovirt-system-tests/commits/add-inventory
-- 
Didi
___
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/SLLNP22SPDPJRWD7FWJ33ZLH5FODK7AH/

[ovirt-devel] Re: Failure to run engine-setup for existing development environment

[Yedidyah Bar David]

On Sun, May 23, 2021 at 1:48 PM Eyal Shenitzky  wrote:
>
> Thanks, that solved the problem.
>
> Is this installed by default on a fresh setup? did we include it in the 
> dependencies?

Yes, and I also updated the README.

>
> On Sun, 23 May 2021 at 12:46, Yedidyah Bar David  wrote:
>>
>> On Sun, May 23, 2021 at 12:42 PM Eyal Shenitzky  wrote:
>> >
>> > Hi,
>> >
>> > When trying to run engine-setup for existing development environment the 
>> > following exception thrown -
>> >
>> > [engine@dhcp-0-123 ~]$ ovirt-engine/bin/engine-setup
>> > ***L:ERROR Internal error: No module named 'distro'
>> > Traceback (most recent call last):
>> >   File "/usr/lib/python3.6/site-packages/otopi/main.py", line 141, in 
>> > execute
>> > self.context.loadPlugins()
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 803, in 
>> > loadPlugins
>> > self._loadPluginGroups(plugindir, needgroups, loadedgroups)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 112, in 
>> > _loadPluginGroups
>> > self._loadPlugins(path, path, groupname)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
>> > _loadPlugins
>> > self._loadPlugins(base, d, groupname)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
>> > _loadPlugins
>> > self._loadPlugins(base, d, groupname)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 100, in 
>> > _loadPlugins
>> > os.path.basename(path),
>> >   File "/usr/lib/python3.6/site-packages/otopi/util.py", line 109, in 
>> > loadModule
>> > spec.loader.exec_module(module)
>> >   File "", line 678, in exec_module
>> >   File "", line 219, in 
>> > _call_with_frames_removed
>> >   File 
>> > "/home/engine/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-checks/ovirt-engine/db/__init__.py",
>> >  line 15, in 
>> > from . import versions
>> >   File 
>> > "/home/engine/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-checks/ovirt-engine/db/versions.py",
>> >  line 21, in 
>> > from ovirt_engine_setup.engine_common import database
>> >   File 
>> > "/home/engine/ovirt-engine/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
>> >  line 27, in 
>> > from ovirt_engine_setup import util as osetuputil
>> >   File 
>> > "/home/engine/ovirt-engine/share/ovirt-engine/setup/ovirt_engine_setup/util.py",
>> >  line 18, in 
>> > import distro
>> > ModuleNotFoundError: No module named 'distro'
>> >
>> > During handling of the above exception, another exception occurred:
>> >
>> > Traceback (most recent call last):
>> >   File "/usr/lib/python3.6/site-packages/otopi/__main__.py", line 88, in 
>> > main
>> > installer.execute()
>> >   File "/usr/lib/python3.6/site-packages/otopi/main.py", line 147, in 
>> > execute
>> > sys.exc_info()[2],
>> >   File "/usr/lib/python3.6/site-packages/otopi/util.py", line 84, in 
>> > raiseExceptionInformation
>> > raise info[1].with_traceback(info[2])
>> >   File "/usr/lib/python3.6/site-packages/otopi/main.py", line 141, in 
>> > execute
>> > self.context.loadPlugins()
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 803, in 
>> > loadPlugins
>> > self._loadPluginGroups(plugindir, needgroups, loadedgroups)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 112, in 
>> > _loadPluginGroups
>> > self._loadPlugins(path, path, groupname)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
>> > _loadPlugins
>> > self._loadPlugins(base, d, groupname)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
>> > _loadPlugins
>> > self._loadPlugins(base, d, groupname)
>> >   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 100, in 
>> > _loadPlugins
>> > os.path.basename(path),
>> >   File "/usr/lib/python3.6/site-packages/otopi/util.py", line 109, in 
>> > loadModule
>

[ovirt-devel] Re: Failure to run engine-setup for existing development environment

[Yedidyah Bar David]

On Sun, May 23, 2021 at 12:42 PM Eyal Shenitzky  wrote:
>
> Hi,
>
> When trying to run engine-setup for existing development environment the 
> following exception thrown -
>
> [engine@dhcp-0-123 ~]$ ovirt-engine/bin/engine-setup
> ***L:ERROR Internal error: No module named 'distro'
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/otopi/main.py", line 141, in execute
> self.context.loadPlugins()
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 803, in 
> loadPlugins
> self._loadPluginGroups(plugindir, needgroups, loadedgroups)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 112, in 
> _loadPluginGroups
> self._loadPlugins(path, path, groupname)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
> _loadPlugins
> self._loadPlugins(base, d, groupname)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
> _loadPlugins
> self._loadPlugins(base, d, groupname)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 100, in 
> _loadPlugins
> os.path.basename(path),
>   File "/usr/lib/python3.6/site-packages/otopi/util.py", line 109, in 
> loadModule
> spec.loader.exec_module(module)
>   File "", line 678, in exec_module
>   File "", line 219, in _call_with_frames_removed
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-checks/ovirt-engine/db/__init__.py",
>  line 15, in 
> from . import versions
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-checks/ovirt-engine/db/versions.py",
>  line 21, in 
> from ovirt_engine_setup.engine_common import database
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
>  line 27, in 
> from ovirt_engine_setup import util as osetuputil
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/ovirt_engine_setup/util.py",
>  line 18, in 
> import distro
> ModuleNotFoundError: No module named 'distro'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/otopi/__main__.py", line 88, in main
> installer.execute()
>   File "/usr/lib/python3.6/site-packages/otopi/main.py", line 147, in execute
> sys.exc_info()[2],
>   File "/usr/lib/python3.6/site-packages/otopi/util.py", line 84, in 
> raiseExceptionInformation
> raise info[1].with_traceback(info[2])
>   File "/usr/lib/python3.6/site-packages/otopi/main.py", line 141, in execute
> self.context.loadPlugins()
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 803, in 
> loadPlugins
> self._loadPluginGroups(plugindir, needgroups, loadedgroups)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 112, in 
> _loadPluginGroups
> self._loadPlugins(path, path, groupname)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
> _loadPlugins
> self._loadPlugins(base, d, groupname)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 69, in 
> _loadPlugins
> self._loadPlugins(base, d, groupname)
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 100, in 
> _loadPlugins
> os.path.basename(path),
>   File "/usr/lib/python3.6/site-packages/otopi/util.py", line 109, in 
> loadModule
> spec.loader.exec_module(module)
>   File "", line 678, in exec_module
>   File "", line 219, in _call_with_frames_removed
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-checks/ovirt-engine/db/__init__.py",
>  line 15, in 
> from . import versions
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-checks/ovirt-engine/db/versions.py",
>  line 21, in 
> from ovirt_engine_setup.engine_common import database
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
>  line 27, in 
> from ovirt_engine_setup import util as osetuputil
>   File 
> "/home/engine/ovirt-engine/share/ovirt-engine/setup/ovirt_engine_setup/util.py",
>  line 18, in 
> import distro
> otopi.main.PluginLoadException: No module named 'distro'
>
> Is this a known issue?

Sorry for not notifying earlier.

You now need python3-distro installed.

See recent patch 'packaging: Support any rhel- or fedora-like distribution'.

Best regards,
-- 
Didi
___
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/6LGZG47LHNPBUHVJ7STFXZ27JTY2FWP5/

[ovirt-devel] Re: Merge rights changes in the oVirt Engine project

[Yedidyah Bar David]

On Wed, Apr 7, 2021 at 6:45 PM Michal Skrivanek
 wrote:
>
>
>
> > On 7. 4. 2021, at 12:04, Yedidyah Bar David  wrote:
> >
> > On Tue, Aug 11, 2020 at 11:05 AM Tal Nisan  wrote:
> >>
> >> Hi everyone,
> >> As you probably know we are now in a mode in which we develop our next 
> >> zstream version on the master branch as opposed to how we worked before 
> >> where the master version was dedicated for the next major version. This 
> >> makes the rapid changes in master to be delivered to customers in a much 
> >> higher cadence thus affecting stability.
> >> Due to that we think it's best that from now on merges in the master 
> >> branch will be done only by stable branch maintainers after inspecting 
> >> those closely.
> >>
> >> What you need to do in order to get your patch merged:
> >> - Have it pass Jenkins
> >> - Have it get code review +2
> >> - Have it mark verified +1
> >> - It's always encourage to have it tested by OST, for bigger changes it's 
> >> a must
> >>
> >> Once you have all those covered, please add me as a reviewer and I'll 
> >> examine it and merge if everything seems right, if I haven't done it in a 
> >> timely manner feel free to ping me.
> >
> > Is the above still the current policy?
>
> Hi Didi,
> well, yes it is. what’s the concern?

No "concern", other than I noticed a few times that people other than
Tal merged patches, and yesterday I did the same [1] after getting +1
from Sandro and consulting him, seeing that I have permissions. IIRC I
didn't have permissions until recently, so I wondered if anything
changed.

If the re-granting of permissions was a mistake, let's revert. If it's
on purpose, perhaps clarify the situation.

[1] https://gerrit.ovirt.org/c/ovirt-engine/+/114130

> I’d love to get to a point when we can automatically gate patches based on 
> OST, but it’s going slow…so for now it’s still manual.

Not sure that's enough, but it would be a step in the right direction.
Sometimes patches won't break OST but are still harmful.

Did we ever consider going fully to Test-Driven-Development? Not
certain if there are studies/methods to calculate/approximate the
expected extra work this will require. Assuming you want eventually
all developers to also know well-enough OST (in addition to their
specific expertise) and be comfortable patching it, it might make
sense.

Best regards,
-- 
Didi
___
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/RAPSZE6V4PW6ZIDXH5F3EBN6XYUABTFO/

[ovirt-devel] Re: Merge rights changes in the oVirt Engine project

[Yedidyah Bar David]

On Tue, Aug 11, 2020 at 11:05 AM Tal Nisan  wrote:
>
> Hi everyone,
> As you probably know we are now in a mode in which we develop our next 
> zstream version on the master branch as opposed to how we worked before where 
> the master version was dedicated for the next major version. This makes the 
> rapid changes in master to be delivered to customers in a much higher cadence 
> thus affecting stability.
> Due to that we think it's best that from now on merges in the master branch 
> will be done only by stable branch maintainers after inspecting those closely.
>
> What you need to do in order to get your patch merged:
> - Have it pass Jenkins
> - Have it get code review +2
> - Have it mark verified +1
> - It's always encourage to have it tested by OST, for bigger changes it's a 
> must
>
> Once you have all those covered, please add me as a reviewer and I'll examine 
> it and merge if everything seems right, if I haven't done it in a timely 
> manner feel free to ping me.

Is the above still the current policy?

Thanks,
-- 
Didi
___
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/5LIRDIAACHT52K7DUFP3WWRHXEUYY6LR/

[ovirt-devel] Re: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 1974 - Still Failing!

[Yedidyah Bar David]

On Wed, Apr 7, 2021 at 12:36 PM Marcin Sobczyk  wrote:
>
>
>
> On 4/6/21 10:37 AM, Marcin Sobczyk wrote:
> >
> > On 4/6/21 9:55 AM, Yedidyah Bar David wrote:
> >> On Tue, Apr 6, 2021 at 9:24 AM Marcin Sobczyk  wrote:
> >>> Hi,
> >>>
> >>> On 4/6/21 7:23 AM, Yedidyah Bar David wrote:
> >>>> On Mon, Apr 5, 2021 at 5:53 AM  wrote:
> >>>>> Project: 
> >>>>> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> >>>>> Build: 
> >>>>> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/1974/
> >>>> FYI: This failed twice in a row (1973 and 1974), for the same reason.
> >>>> I reproduced locally, looked a bit, failed to find the root cause.
> >>>> When I connected
> >>>> to host-1's console, it was stuck in emergency after reboot. I checked
> >>>> a bit, there
> >>>> was some error about kdump failing to read the kernel image
> >>>> ( /boot/vmlinuz-4.18.0-240.15.1.el8_3.x86_64 ), when I tried manually
> >>>> as root I did
> >>>> manage to read it. I rebooted, and the VM came up fine. I decided to
> >>>> try OST again,
> >>>> cleaned up and ran it, and opened a 'lago console' on the vm after it
> >>>> was up, but
> >>>> OST passed. Tried again, passed again. Then I manually ran in CI 1975
> >>>> and it passed,
> >>>> and also the nightly 1976 passed. So I am going to ignore for now.
> >>>>
> >>>> I think we need a patch to make lago/OST log consoles of all the VMs.
> >>>> I might try
> >>>> to work on this.
> >>> Also stumbled upon this. Please take a look at
> >>> https://gerrit.ovirt.org/#/c/ovirt-system-tests/+/114050/
> >> Yes, I did notice this change and wondered if it's related...
> >>
> >> But it's not merged yet, and still HE passed at least 4 times (two locally,
> >> two on CI). Obviously this does not prove that the issue is fixed.
> >>
> >> Anyway, in addition to merely fixing it (which perhaps your patch does),
> >> I also wanted to emphasize the importance of making it easier to fix
> >> future such cases. How did you manage to find the root cause?
> > My case was similar - HE suite was failing for me constantly. I noticed
> > host-1 drops to emergency shell, so I just 'virsh console'd inside
> > and went through the logs. That's when I spotted the problem with
> > the additional '/var/tmp' disk. I tried the fix on my machine and HE
> > suite started working again. Moments later I tried running HE suite
> > without the patch and it was successful again.
> >
> > I couldn't figure out what's the real cause behind these problems,
> > but removing the unnecessary additional disk from host-1 seemed
> > to do the trick.
> >
> > +1 for logging consoles of the VMs - that should help with these kind
> > of problems in the future.
> Yesterday we hit this problem at least 2 times:
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/16183
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/16184
>
> Didi, please review the patch mentioned above. If you don't have
> any objections let's merge it and work on improving logging later.

+1 from me.

I also pushed this to log consoles, but it's not as easy as hoped:

https://gerrit.ovirt.org/c/lago-ost/+/114150

When you have time, please see my comment there and reply...

Thanks and best regards,
-- 
Didi
___
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/INUYPDJR3GESUVOS7YBKMHEAP5KO4QAH/

[ovirt-devel] Re: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 1974 - Still Failing!

[Yedidyah Bar David]

On Tue, Apr 6, 2021 at 9:24 AM Marcin Sobczyk  wrote:
>
> Hi,
>
> On 4/6/21 7:23 AM, Yedidyah Bar David wrote:
> > On Mon, Apr 5, 2021 at 5:53 AM  wrote:
> >> Project: 
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> >> Build: 
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/1974/
> > FYI: This failed twice in a row (1973 and 1974), for the same reason.
> > I reproduced locally, looked a bit, failed to find the root cause.
> > When I connected
> > to host-1's console, it was stuck in emergency after reboot. I checked
> > a bit, there
> > was some error about kdump failing to read the kernel image
> > ( /boot/vmlinuz-4.18.0-240.15.1.el8_3.x86_64 ), when I tried manually
> > as root I did
> > manage to read it. I rebooted, and the VM came up fine. I decided to
> > try OST again,
> > cleaned up and ran it, and opened a 'lago console' on the vm after it
> > was up, but
> > OST passed. Tried again, passed again. Then I manually ran in CI 1975
> > and it passed,
> > and also the nightly 1976 passed. So I am going to ignore for now.
> >
> > I think we need a patch to make lago/OST log consoles of all the VMs.
> > I might try
> > to work on this.
> Also stumbled upon this. Please take a look at
> https://gerrit.ovirt.org/#/c/ovirt-system-tests/+/114050/

Yes, I did notice this change and wondered if it's related...

But it's not merged yet, and still HE passed at least 4 times (two locally,
two on CI). Obviously this does not prove that the issue is fixed.

Anyway, in addition to merely fixing it (which perhaps your patch does),
I also wanted to emphasize the importance of making it easier to fix
future such cases. How did you manage to find the root cause?

Best regards,
-- 
Didi
___
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/U6I3ZGEPJF4PA2NRMP7HKNMAQIL5REV2/

[ovirt-devel] Re: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 1974 - Still Failing!

[Yedidyah Bar David]

On Mon, Apr 5, 2021 at 5:53 AM  wrote:
>
> Project: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/
> Build: 
> https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/1974/

FYI: This failed twice in a row (1973 and 1974), for the same reason.
I reproduced locally, looked a bit, failed to find the root cause.
When I connected
to host-1's console, it was stuck in emergency after reboot. I checked
a bit, there
was some error about kdump failing to read the kernel image
( /boot/vmlinuz-4.18.0-240.15.1.el8_3.x86_64 ), when I tried manually
as root I did
manage to read it. I rebooted, and the VM came up fine. I decided to
try OST again,
cleaned up and ran it, and opened a 'lago console' on the vm after it
was up, but
OST passed. Tried again, passed again. Then I manually ran in CI 1975
and it passed,
and also the nightly 1976 passed. So I am going to ignore for now.

I think we need a patch to make lago/OST log consoles of all the VMs.
I might try
to work on this.

Best regards,
-- 
Didi
___
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/5KFG3KDMTKU63253F5DYHJ2QGTSDNMEO/

[ovirt-devel] ovirt-system-tests hosted-engine suites and CentOS Stream - current status

[Yedidyah Bar David]

Hi all,

Right now, ovirt appliance is built nightly, and publishes (to
ovirt-master-snapshot) two packages: ovirt-engine-appliance (the
"regular" one, based on CentOS Linux) and
ovirt-engine-appliance-centos-stream (based on CentOS Stream).

This can already be used by anyone that wants to try this manually.

For trying in CI:

1. A pending patch to ost-images [1] can be merged once it passes the
manual build I ran (link in a gerrit comment there). Should take a few
more hours. This patch changes the existing image that was generated,
called ost-images-el8stream-he-installed, to include a stream
appliance (from current repos).

2. A patch for OST [2] can be used, as needed, for manual runs. I
updated it now to expect the output of [1] once it's merged, so should
probably be rebased and/or 'ci test/ci build' once [1] is merged (and
image is published).

TODO:

1. Decide how we want to continue, going forward. If we aim at
complete move to Stream in 4.4.6, perhaps now is the time to start...
An alternative is to somehow support both in parallel - will be more
complex, obviously.

2. Handle ovirt-node

Best regards,

[1] https://gerrit.ovirt.org/c/ost-images/+/113633

[2] https://gerrit.ovirt.org/c/ovirt-system-tests/+/112977
-- 
Didi
___
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/E4XSDRJ544LI42I7C2254NLG36TPL7MB/

[ovirt-devel] Re: basic suite fails on test_metrics_and_log_collector

[Yedidyah Bar David]

On Wed, Mar 17, 2021 at 5:38 PM Yedidyah Bar David  wrote:
>
> On Wed, Mar 17, 2021 at 4:48 PM Martin Perina  wrote:
> >
> >
> >
> > On Wed, Mar 17, 2021 at 3:24 PM Michal Skrivanek 
> >  wrote:
> >>
> >>
> >>
> >> On 17. 3. 2021, at 13:53, Dana Elfassy  wrote:
> >>
> >> Adding +Marcin Sobczyk
> >>
> >> On Mon, Mar 15, 2021 at 9:59 AM Yedidyah Bar David  wrote:
> >>>
> >>> On Mon, Mar 15, 2021 at 7:55 AM Yedidyah Bar David  
> >>> wrote:
> >>> >
> >>> > Hi all,
> >>> >
> >>> > This started a few days ago [1] and randomly happens since then:
> >>> >
> >>> > E   DEBUG: Configuration:
> >>> > E   DEBUG: command: collect
> >>> > E   DEBUG: Traceback (most recent call last):
> >>> > E   DEBUG:   File
> >>> > "/usr/lib/python3.6/site-packages/ovirt_log_collector/__main__.py",
> >>> > line 2067, in 
> >>> > E   DEBUG: '%s directory is not empty.' % 
> >>> > (conf["local_tmp_dir"])
> >>> > E   DEBUG: Exception: /dev/shm/log directory is not
> >>> > empty.ERROR: /dev/shm/log directory is not empty.non-zero return code
> >>> >
> >>> > Michal tried to fix this by using a random directory but it still fails 
> >>> > [2]:
> >>> >
> >>> > DEBUG: command: collect
> >>> > DEBUG: Traceback (most recent call last):
> >>> > DEBUG:   File 
> >>> > "/usr/lib/python3.6/site-packages/ovirt_log_collector/__main__.py",
> >>> > line 2067, in 
> >>> > DEBUG: '%s directory is not empty.' % (conf["local_tmp_dir"])
> >>> > DEBUG: Exception: /dev/shm/kaN7uY directory is not empty.ERROR:
> >>> > /dev/shm/kaN7uY directory is not empty.non-zero return code
> >>> >
> >>> > Since I suppose that the randomness of mktemp is good enough, it must
> >>> > be something else. Also, the last successful run before [1] used the
> >>> > same OST git commit (same code), so I do not think it's something in
> >>> > OST's code.
> >>> >
> >>> > Any idea?
> >>> >
> >>> > I think I'll push a patch to create and use the directory right before
> >>> > calling ovirt-log-collector, which is probably better in other ways.
> >>>
> >>> My patch [1] still fails, with a somewhat different error message, but
> >>> this made me check further, and while I still do not understand, I have
> >>> this to add:
> >>>
> >>> In the failing runs, ovirt-log-collector is called *twice* in parallel. 
> >>> E.g.
> >>> in [2] (the check-patch of [1]):
> >>>
> >>> Mar 15 07:38:59 lago-basic-suite-master-engine platform-python[59099]:
> >>> ansible-command Invoked with _raw_params=lctmp=$(mktemp -d -p
> >>> /dev/shm); ovirt-log-collector --verbose --batch --no-hypervisors
> >>> --local-tmp="${lctmp}" --conf-file=/root/ovirt-log-collector.conf
> >>> _uses_shell=True warn=True stdin_add_newline=True
> >>> strip_empty_ends=True argv=None chdir=None executable=None
> >>> creates=None removes=None stdin=None
> >>> Mar 15 07:38:59 lago-basic-suite-master-engine platform-python[59124]:
> >>> ansible-command Invoked with _raw_params=lctmp=$(mktemp -d -p
> >>> /dev/shm); ovirt-log-collector --verbose --batch --no-hypervisors
> >>> --local-tmp="${lctmp}" --conf-file=/root/ovirt-log-collector.conf
> >>> _uses_shell=True warn=True stdin_add_newline=True
> >>> strip_empty_ends=True argv=None chdir=None executable=None
> >>> creates=None removes=None stdin=None
> >>>
> >>> It also generates two logs, which you can check/compare.
> >>>
> >>> It's the same for previous ones, e.g. latest nightly [3][4]:
> >>>
> >>> Mar 15 06:23:30 lago-basic-suite-master-engine platform-python[59343]:
> >>> ansible-command Invoked with _raw_params=ovirt-log-collector --verbose
> >>> --batch --no-hypervisors --conf-file=/root/ovirt-log-collector.conf
> >>> _uses_shell=True warn=True stdin_add_newline=True
> >>> strip_empty_ends=True argv=None chdir=None executable=None
> >>> creates=None removes=None stdin=None
> &g

[ovirt-devel] Re: basic suite fails on test_metrics_and_log_collector

[Yedidyah Bar David]

On Wed, Mar 17, 2021 at 4:48 PM Martin Perina  wrote:
>
>
>
> On Wed, Mar 17, 2021 at 3:24 PM Michal Skrivanek 
>  wrote:
>>
>>
>>
>> On 17. 3. 2021, at 13:53, Dana Elfassy  wrote:
>>
>> Adding +Marcin Sobczyk
>>
>> On Mon, Mar 15, 2021 at 9:59 AM Yedidyah Bar David  wrote:
>>>
>>> On Mon, Mar 15, 2021 at 7:55 AM Yedidyah Bar David  wrote:
>>> >
>>> > Hi all,
>>> >
>>> > This started a few days ago [1] and randomly happens since then:
>>> >
>>> > E   DEBUG: Configuration:
>>> > E   DEBUG: command: collect
>>> > E   DEBUG: Traceback (most recent call last):
>>> > E   DEBUG:   File
>>> > "/usr/lib/python3.6/site-packages/ovirt_log_collector/__main__.py",
>>> > line 2067, in 
>>> > E   DEBUG: '%s directory is not empty.' % 
>>> > (conf["local_tmp_dir"])
>>> > E   DEBUG: Exception: /dev/shm/log directory is not
>>> > empty.ERROR: /dev/shm/log directory is not empty.non-zero return code
>>> >
>>> > Michal tried to fix this by using a random directory but it still fails 
>>> > [2]:
>>> >
>>> > DEBUG: command: collect
>>> > DEBUG: Traceback (most recent call last):
>>> > DEBUG:   File 
>>> > "/usr/lib/python3.6/site-packages/ovirt_log_collector/__main__.py",
>>> > line 2067, in 
>>> > DEBUG: '%s directory is not empty.' % (conf["local_tmp_dir"])
>>> > DEBUG: Exception: /dev/shm/kaN7uY directory is not empty.ERROR:
>>> > /dev/shm/kaN7uY directory is not empty.non-zero return code
>>> >
>>> > Since I suppose that the randomness of mktemp is good enough, it must
>>> > be something else. Also, the last successful run before [1] used the
>>> > same OST git commit (same code), so I do not think it's something in
>>> > OST's code.
>>> >
>>> > Any idea?
>>> >
>>> > I think I'll push a patch to create and use the directory right before
>>> > calling ovirt-log-collector, which is probably better in other ways.
>>>
>>> My patch [1] still fails, with a somewhat different error message, but
>>> this made me check further, and while I still do not understand, I have
>>> this to add:
>>>
>>> In the failing runs, ovirt-log-collector is called *twice* in parallel. E.g.
>>> in [2] (the check-patch of [1]):
>>>
>>> Mar 15 07:38:59 lago-basic-suite-master-engine platform-python[59099]:
>>> ansible-command Invoked with _raw_params=lctmp=$(mktemp -d -p
>>> /dev/shm); ovirt-log-collector --verbose --batch --no-hypervisors
>>> --local-tmp="${lctmp}" --conf-file=/root/ovirt-log-collector.conf
>>> _uses_shell=True warn=True stdin_add_newline=True
>>> strip_empty_ends=True argv=None chdir=None executable=None
>>> creates=None removes=None stdin=None
>>> Mar 15 07:38:59 lago-basic-suite-master-engine platform-python[59124]:
>>> ansible-command Invoked with _raw_params=lctmp=$(mktemp -d -p
>>> /dev/shm); ovirt-log-collector --verbose --batch --no-hypervisors
>>> --local-tmp="${lctmp}" --conf-file=/root/ovirt-log-collector.conf
>>> _uses_shell=True warn=True stdin_add_newline=True
>>> strip_empty_ends=True argv=None chdir=None executable=None
>>> creates=None removes=None stdin=None
>>>
>>> It also generates two logs, which you can check/compare.
>>>
>>> It's the same for previous ones, e.g. latest nightly [3][4]:
>>>
>>> Mar 15 06:23:30 lago-basic-suite-master-engine platform-python[59343]:
>>> ansible-command Invoked with _raw_params=ovirt-log-collector --verbose
>>> --batch --no-hypervisors --conf-file=/root/ovirt-log-collector.conf
>>> _uses_shell=True warn=True stdin_add_newline=True
>>> strip_empty_ends=True argv=None chdir=None executable=None
>>> creates=None removes=None stdin=None
>>> Mar 15 06:23:30 lago-basic-suite-master-engine setroubleshoot[58889]:
>>> SELinux is preventing /usr/lib/systemd/systemd from unlink access on
>>> the sock_file ansible-ssh-lago-basic-suite-master-host-1-22-root. For
>>> complete SELinux messages run: sealert -l
>>> d03a8655-9430-4fcf-9892-3b4df1939899
>>> Mar 15 06:23:30 lago-basic-suite-master-engine setroubleshoot[58889]:
>>> SELinux is preventing /usr/lib/systemd/systemd from unlink access on
>>> the s

[ovirt-devel] Re: [oVirt Jenkins] ovirt-system-tests_basic-suite-master_nightly - Build # 962 - Still Failing!

[Yedidyah Bar David]

On Tue, Mar 16, 2021 at 6:02 PM Michal Skrivanek 
wrote:

>
>
> On 16. 3. 2021, at 15:53, Yedidyah Bar David  wrote:
>
> On Tue, Mar 16, 2021 at 10:09 AM Yedidyah Bar David 
> wrote:
>
>
> On Tue, Mar 16, 2021 at 7:06 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/962/
> Build Number: 962
> Build Status:  Still Failing
> Triggered By: Started by timer
>
> -
> Changes Since Last Success:
> -
> Changes for Build #953
> [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
>
>
> Changes for Build #954
> [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
>
>
> Changes for Build #955
> [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
>
>
> Changes for Build #956
> [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
>
>
> Changes for Build #957
> [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
>
>
> Changes for Build #958
> [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
>
>
> Changes for Build #959
> [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
>
>
> Changes for Build #960
> [Andrej Cernek] pylint: Upgrade to 2.7
>
>
> Changes for Build #961
> [Andrej Cernek] pylint: Upgrade to 2.7
>
>
> Changes for Build #962
> [Andrej Cernek] pylint: Upgrade to 2.7
>
>
>
>
> -
> Failed Tests:
> -
> 1 tests failed.
> FAILED:
>  
> basic-suite-master.test-scenarios.test_001_initialize_engine.test_set_hostnames
>
> Error Message:
> failed on setup with "TypeError: __new__() missing 2 required positional
> arguments: 'version' and 'repo'"
>
> Stack Trace:
> ansible_by_hostname = 
>
>@pytest.fixture(scope="session", autouse=True)
>def check_installed_packages(ansible_by_hostname):
>vms_pckgs_dict_list = []
>for hostname in backend.default_backend().hostnames():
>vm_pckgs_dict = _get_custom_repos_packages(
>
>  ansible_by_hostname(hostname))
>
>
> ost_utils/ost_utils/pytest/fixtures/check_repos.py:39:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _
> ost_utils/ost_utils/pytest/fixtures/check_repos.py:55: in
> _get_custom_repos_packages
>repo_name)
> ost_utils/ost_utils/pytest/fixtures/check_repos.py:69: in
> _get_installed_packages
>Package(*line) for line in result
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _
>
> .0 = 
>
>  Package(*line) for line in result
>
>]
> E   TypeError: __new__() missing 2 required positional arguments:
> 'version' and 'repo'
>
>
> This failed, because 'dnf repo-pkgs' has split the output to two
> lines, so the first
> didn't include a version [1]:
>
> lago-basic-suite-master-host-1 | CHANGED | rc=0 >>
> Installed Packages
> ovirt-ansible-collection.noarch 1.3.2-0.1.master.20210315141358.el8
> @extra-src-1
> python3-ovirt-engine-sdk4.x86_64
>4.4.10-1.20210315.gitf8b9f2a.el8
>@extra-src-1
>
> We should either give up on this, or rewrite the call 'dnf repo-pkgs'
> in some other
> language that does not require parsing of human-targeted output
> (perhaps python or
> ansible), or amend a bit the current code and hope it will survive
> longer...
>
> Trying last one:
>
> https://gerrit.ovirt.org/c/ovirt-system-tests/+/113895
>
>
> Merged, but we still fail in nightly (which I ran manually):
>
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/963/console
>
> 16:06:44 >   raise RuntimeError('None of user custom repos has
> been used')
> 16:06:44 E   RuntimeError: None of user custom repos has been used
>
> I think this is "by design" - this job runs with a "custom repo"
> pointing at master-snapshot, and apparently at least in this run it
> didn't see updates, so failed.
>
>
> wouldn’t it fail exactly during the night when we build a fresh ost-image
> and run with custom repo that has nothing newer, obviously, since we just
> built the image?
>

In principle, yes, but in practice we did have some runs that did not fail.
I looked a bit trying to understand why they didn't fail and gave up,
deciding it's not that important. I think it's related to the timing of
these jobs and the publisher, ost-images, etc.


>
>
> I wonder if this is simply a

[ovirt-devel] Re: [oVirt Jenkins] ovirt-system-tests_basic-suite-master_nightly - Build # 962 - Still Failing!

[Yedidyah Bar David]

On Tue, Mar 16, 2021 at 10:09 AM Yedidyah Bar David  wrote:
>
> On Tue, Mar 16, 2021 at 7:06 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/962/
> > Build Number: 962
> > Build Status:  Still Failing
> > Triggered By: Started by timer
> >
> > -
> > Changes Since Last Success:
> > -
> > Changes for Build #953
> > [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
> >
> >
> > Changes for Build #954
> > [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
> >
> >
> > Changes for Build #955
> > [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
> >
> >
> > Changes for Build #956
> > [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
> >
> >
> > Changes for Build #957
> > [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
> >
> >
> > Changes for Build #958
> > [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
> >
> >
> > Changes for Build #959
> > [Michal Skrivanek] randomize /dev/shm logcollector tmp directory
> >
> >
> > Changes for Build #960
> > [Andrej Cernek] pylint: Upgrade to 2.7
> >
> >
> > Changes for Build #961
> > [Andrej Cernek] pylint: Upgrade to 2.7
> >
> >
> > Changes for Build #962
> > [Andrej Cernek] pylint: Upgrade to 2.7
> >
> >
> >
> >
> > -
> > Failed Tests:
> > -
> > 1 tests failed.
> > FAILED:  
> > basic-suite-master.test-scenarios.test_001_initialize_engine.test_set_hostnames
> >
> > Error Message:
> > failed on setup with "TypeError: __new__() missing 2 required positional 
> > arguments: 'version' and 'repo'"
> >
> > Stack Trace:
> > ansible_by_hostname = 
> >
> > @pytest.fixture(scope="session", autouse=True)
> > def check_installed_packages(ansible_by_hostname):
> > vms_pckgs_dict_list = []
> > for hostname in backend.default_backend().hostnames():
> > vm_pckgs_dict = _get_custom_repos_packages(
> > >   ansible_by_hostname(hostname))
> >
> > ost_utils/ost_utils/pytest/fixtures/check_repos.py:39:
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _
> > ost_utils/ost_utils/pytest/fixtures/check_repos.py:55: in 
> > _get_custom_repos_packages
> > repo_name)
> > ost_utils/ost_utils/pytest/fixtures/check_repos.py:69: in 
> > _get_installed_packages
> > Package(*line) for line in result
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _
> >
> > .0 = 
> >
> > >   Package(*line) for line in result
> > ]
> > E   TypeError: __new__() missing 2 required positional arguments: 'version' 
> > and 'repo'
>
> This failed, because 'dnf repo-pkgs' has split the output to two
> lines, so the first
> didn't include a version [1]:
>
> lago-basic-suite-master-host-1 | CHANGED | rc=0 >>
> Installed Packages
> ovirt-ansible-collection.noarch 1.3.2-0.1.master.20210315141358.el8 
> @extra-src-1
> python3-ovirt-engine-sdk4.x86_64
> 4.4.10-1.20210315.gitf8b9f2a.el8
> @extra-src-1
>
> We should either give up on this, or rewrite the call 'dnf repo-pkgs'
> in some other
> language that does not require parsing of human-targeted output
> (perhaps python or
> ansible), or amend a bit the current code and hope it will survive longer...
>
> Trying last one:
>
> https://gerrit.ovirt.org/c/ovirt-system-tests/+/113895

Merged, but we still fail in nightly (which I ran manually):

https://jenkins.ovirt.org/job/ovirt-system-tests_basic-suite-master_nightly/963/console

16:06:44 >   raise RuntimeError('None of user custom repos has
been used')
16:06:44 E   RuntimeError: None of user custom repos has been used

I think this is "by design" - this job runs with a "custom repo"
pointing at master-snapshot, and apparently at least in this run it
didn't see updates, so failed.

I wonder if this is simply a design issue, or we should change the
nightly run to not use a custom repo, or something else.

In any case, perhaps we should consider completely reverting
check_repos.py for now, until we decide what we want. It was a good
idea, but we can't let basic-suite remain red for so long. And then,
we can get back to the issue of ovirt-log-collector...

Best regards,
-- 
Didi
___
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/XA6E4AFRT7SDMZX23QZGJ3XJV3KVDMY5/

[ovirt-devel] Re: Engine upgrade fails with virtio_scsi_multi_queues_enabled does not exist

[Yedidyah Bar David]

On Tue, Mar 16, 2021 at 9:21 AM Vojtech Juranek  wrote:
>
> On Tuesday, 16 March 2021 07:08:31 CET Yedidyah Bar David wrote:
> > On Mon, Mar 15, 2021 at 10:48 PM Vojtech Juranek 
> wrote:
> > > Hi,
> > > when I try to upgrade my engine with built artifacts (e.g. [1]), it fails
> > > with:
> > >
> > > psql:/usr/share/ovirt-engine/dbscripts/create_views.sql:1000: ERROR:
> > > column vm_templates.virtio_scsi_multi_queues_enabled does not exist LINE
> > > 86: vm_templates.virtio_scsi_multi_queues_enabled AS virtio_...>
> > >  ^
> > >
> > > FATAL: Cannot execute sql command:
> > > --file=/usr/share/ovirt-engine/dbscripts/create_views.sql
> > >
> > > Same issue happens when I tried to update my dev engine with local build.
> > > However, OST is passing [2].
> > >
> > > Any idea what's wrong? I don't see anything wrong in [3], which is
> > > probably the culprit, but I haven't much experience with engine/db
> > > though. Or maybe some issue on my side?
> > I suppose this failure happens in engine-setup, right? Please share
> > its logs. Thanks.
>
> attached

Thanks. It has:

2021-03-15 16:28:56,292-0400 Skipping upgrade script
/usr/share/ovirt-engine/dbscripts/upgrade/04_04_1010_add_virtio_scsi_multi_queues_enabled_to_vm_static.sql,
its version 04041010 is <= current version 04041010

"current version" should be the version of the latest dbscript you
applied to your db.

In current master branch, this version (04041010) belongs to above script.

Perhaps you have/had some other dbscript with this number (meaning,
prefix 04_04_1010)? Perhaps chec/share the output of 'select * from
schema_version order by id;', and 'ls -l packaging/dbscripts/upgrade'
(although this might have been updated. The db is more relevant).

>
> > Best regards,
> >
> > > Thanks
> > > Vojta
> > >
> > > [1]
> > > https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/11174/art
> > > ifact/check-patch.el8.x86_64/ [2]
> > > https://jenkins.ovirt.org/job/ovirt-system-tests_manual/7880/
> > > [3]
> > > https://github.com/oVirt/ovirt-engine/commit/52caf76e60ace2266d8283c131d4
> > > 673a2dd79289___ 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/DWCUVM4HRGV
> > > SUNLCS3TWL4LHKXDD2NPO/
>


-- 
Didi
___
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/K5G7GEY7ED5MWU2SXYDROF5T2VHS2G7R/