[ovirt-devel] review request: SDM update_volume API changes

[Germano Veit Michel]

Hello,

Could you please review and comment on the following patch series below?
https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:snapshot-tools-api

These are required by future tools to make fixing image chains safer and
easier.

This has been previously submitted as part of a larger set of patches,
which were not accepted mostly due to a ResourceManager Exception
workaround (force flag). The series above removes that workaround and also
improves the tests.

I'm only submitting the API changes at this time. If you want to have an
idea on what this will be used for, please see now abandoned
https://gerrit.ovirt.org/#/c/94105/ (it will get updated and resubmitted
once and if these API changes are accepted)

Thanks,
Germano
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/PZ7KTTGA2V642PL7MTDRPZW3BOKD4HKH/

[ovirt-devel] Re: Failed to add fedora-29 host to oVirt

[Eyal Shenitzky]

On Tue, Jun 11, 2019 at 7:01 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno mar 11 giu 2019 alle ore 11:15 Eyal Shenitzky <
> eshen...@redhat.com> ha scritto:
>
>> Hi,
>>
>> I am trying to add fedora-29 host to me oVirt setup and failed due to the
>> following error (from the engine log):
>>
>> 2019-06-11 11:24:59,123+03 ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An
>> error has occurred during installation of Host fedora_29: DNF   Problem:
>> conflicting requests   - package
>> ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires
>> ovirt-hosted-engine-setup, but none of the providers can be installed   -
>> package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
>> does not have a compatible architecture   - nothing provides
>> ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29
>> needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
>>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>>   - nothing provides vdsm-python >= 4.30 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>>   - nothing provides glusterfs-cli >= 5.6 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>>   - nothing provides vdsm-python >= 4.40.0 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch.
>> 2019-06-11 11:24:59,133+03 ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An
>> error has occurred during installation of Host fedora_29: Failed to execute
>> stage 'Package installation':   Problem: conflicting requests   - package
>> ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires
>> ovirt-hosted-engine-setup, but none of the providers can be installed   -
>> package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
>> does not have a compatible architecture   - nothing provides
>> ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29
>> needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
>>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>>   - nothing provides vdsm-python >= 4.30 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>>   - nothing provides glusterfs-cli >= 5.6 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>>   - nothing provides vdsm-python >= 4.40.0 needed by
>> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch.
>>
>> When I try to install VDSM manually before adding the host the setup it
>> installed the following version:
>> vdsm-4.18.999-447.git0bb7717.fc28.x86_64
>>
>>
>> Any suggestions?
>>
>
> fix vdsm build on fc29 :-)
> currently fc29 build for vdsm is not happening, I pushed a few patches
> helping getting it working but definitely more help is needed to get it
> working on fc29.
>
>
What is currently missing?
Is someone is responsible for fixing it?




>
>
>>
>> --
>> Regards,
>> Eyal Shenitzky
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7FXMS3A22OSHR3GWQNT7IFANW6QXB7RY/
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>


-- 
Regards,
Eyal Shenitzky
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/LAGTI2PNGVVOU3OZEGCPZOLALFG56DZ6/

[ovirt-devel] Re: Building python 2 and python 3 packages for Fedora

[Nir Soffer]

On Thu, Jun 6, 2019 at 9:10 AM Yedidyah Bar David  wrote:

> On Wed, Jun 5, 2019 at 6:21 PM Nir Soffer  wrote:
> >
> > In several projects (e.g. vdsm, imageio, sanlock), we have the issue of
> building python 3 packages
> > for Fedora.
> >
> > The current build process create packages with the same name for both
> python 2 and python 3.
> > When the packages are published to oVirt repository, the python 3
> packages overwrite the python 2
> > packages.
> >
> > We can rename the packages properly (e.g. python2-xxx, python3-xxx) but
> this requires lot of work
> > and typically breaks later in the code publishing the packages.
> >
> > There is also the difficulty of building both python 2 and python 3
> packages from same spec in the same
> > build. This should be possible but not easy.
>
> I agree about both, but we already have several projects that do
> exactly that, so we do have some experience.
>
> >
> > Since python 2 is about to die soon, should we simplify by building
> python 2 *or* python 3, depending
> > on version?
> >
> > Fedora 29: python 2.7
> > Fedora 30: python 3.7
> > CentOS 7: python 2.7
> > CentOS 8: python 3.6


> Generally speaking, this is the approach we took with stand-alone
> tools, e.g. ovirt-iso-uploader, ovirt-engine*setup*.
>
> With libraries, we did package for both - e.g. otopi (not a pure
> library, but not a standalone tool either), ovirt-engine-lib.
>
> >
> > This make it possible to test and develop on python 2.7 until vdsm is
> fully functional on python 3,
> > and it save resources in the CI.
>
> vdsm is similar to the (python code in the) engine, in that regard.
> Most of it is a set of standalone tools, but some parts are libraries,
> also used by external tools.
>

The only users of vdsm code are mom and hosted engine that can be used
anyway on python 3 before vdsm will be compatible with python 3, so I don't
see a reason to invest in this direction, and we also don't have capacity
to
do this anyway.

> If you package the libraries for only a single version of python, you
> require all the 3rd-party tools to adapt their python support exactly
> at same cadence of vdsm. By providing libraries for both, at least for
> some time, you allow a smoother transition. If you want to avoid that,
> I guess it's best to enumerate the current users of vdsm library code,
> and coordinate with these. This includes hosted-engine*, but perhaps
> also others, not sure.


Good point, but we are 5 years late.

This plan also works sanlock. We will release this week sanlock 3.8 for El
8.1
and Fedora 30 - only for python 3.

I discussed this with Dan offline and he is happy with this plan.

Nir
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/6LRUFWGYAKU5OSZJRMVQ3MSNKOEORBXT/

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Martin Perina]

On Tue, Jun 11, 2019 at 7:41 PM Martin Perina  wrote:

>
>
> On Tue, Jun 11, 2019 at 6:53 PM Dafna Ron  wrote:
>
>> Galit's patch should have solved it.
>> Marcin, are you still failing?
>>
>
> I've just rebased https://gerrit.ovirt.org/100716 on top of Galit's
> change so we should know within an hour or so ...
>

CI finished successfully, please review so we can merge ...


>
>>
>> On Tue, Jun 11, 2019 at 2:40 PM Eyal Edri  wrote:
>>
>>>
>>>
>>> On Tue, Jun 11, 2019 at 4:35 PM Marcin Sobczyk 
>>> wrote:
>>>
 Hi,

 basic suite fails for the patch with the following log:

  
 [2019-06-11T11:34:26.175Z]
- STDERR
  
 [2019-06-11T11:34:26.175Z]
  + yum -y install ovirt-host
  
 [2019-06-11T11:34:26.175Z]
  Error: Package: 32:bind-libs-9.9.4-74.el7_6.1.x86_64 (alocalsync)
  
 [2019-06-11T11:34:26.175Z]
 Requires: bind-license = 32:9.9.4-74.el7_6.1
  
 [2019-06-11T11:34:26.175Z]
 Installed: 32:bind-license-9.9.4-73.el7_6.noarch (installed)
  
 [2019-06-11T11:34:26.175Z]
 bind-license = 32:9.9.4-73.el7_6


>>> I think https://gerrit.ovirt.org/#/c/100691/ which was merged 2 hours
>>> ago should address this issue.
>>> Maybe other reposync files should be updated as well?
>>>
>>>
  Seems unrelated and I'm having the same issue locally on my server.
 Dafna, do you have some insight regarding this dependency error?

 Thanks, Marcin
 On 6/11/19 1:15 PM, Martin Perina wrote:



 On Tue, Jun 11, 2019 at 11:58 AM Milan Zamazal 
 wrote:

> Dafna Ron  writes:
>
> > Hi,
> >
> > Please note vdsm has been broken since Fri the 7th
> >
> > to summarize again,  vdsm has a patch to remove sos plugin which is
> what
> > metrics is using in its ost tests
> > due to that, vdsm is failing the metrics tests and in order to solve
> it we
> > need to make a choice:
> > 1. fix the metrics tests to not use sos
> > 2. disable the metrics tests
> > 3. revert the sos patch until a decision is made on ^^
>
> #3 is not an option, it would make Vdsm uninstallable on newer RHEL
> versions.
>

 I've posted a patch https://gerrit.ovirt.org/100716 which is trying to
 install vdsm sos plugin if it's not installed either by vdsm nor sos.
 Currenlty waiting for CI, if run is successfull, I will extend the
 patch also for 4.3 basic suite.


> > Thanks,
> > Dafna
> >
> >
> > -- Forwarded message -
> > From: Dafna Ron 
> > Date: Mon, Jun 10, 2019 at 1:30 PM
> > Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [
> 07-06-2019 ]
> > [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
> > To: Martin Perina , Milan Zamazal <
> mzama...@redhat.com>,
> > Shirly Radco 
> > Cc: devel , infra 
> >
> >
> > Shirly? any update on this?
> >
> > On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:
> >
> >> Hi,
> >>
> >> We have a failure in vdsm project on master.
> >>
> >> The issue is change:
> >> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
> >>
> >> which is failing on metrics as metrics is calling sos-logcollector.
> >>
> >> The patch cannot be changed as until centos 7.7 when sos-3.7-3,
> which
> >> contains vdsm plugin will come out.
> >> so until then, we are left with no sos plugin, which is causing the
> >> metrics test to fail.
> >>
> >> Shirly, can you please take a look and see if we can change the
> test to
> >> not call sos-logcollector?
> >> Please note, that we are expecting 4.3 to fail on same issue very
> soon.
> >>
> >> failed job can be found here:
> >>
> >>
> https://jenkins.ovirt.org/job/ovirt-master_cha

[ovirt-devel] Issues when running VDSM tests

[Pavel Bar]

Hi Milan,
Can you please check the following VDSM tests's failures:

*Environment:*
1) VDSM master branch;
2) Fedora 29 OS

*Execution (from root folder):*
*make check*

*Issues:*
1) An authentication pop-up window jumps when executing:


*Warning no default label for
/tmp/tmpRCRsYm/libvirtd.SS.S.SS..SS.S..SSS..S..SSS.SSS..SSS...S....SS.S.S.S.S.SSS..S..S.SS.--*

2) 2 error outputs received, the 2nd one multiple times:

*ERROR: InvocationError for command
'/home/pbar/Dev/git/vdsm/pbar/master/tests/profile network-py27 ./py-watch
600 pytest --durations=5 --cov=vdsm.network
--cov-report=html:htmlcov-network-py27 --cov-fail-under=42
network/integration network/unit' (exited with code 1)*



*E   HookError: Hook Error: ('Traceback (most recent call
last):\n  File "/usr/libexec/vdsm/hooks/before_nic_hotplug/50_vmfex", line
35, in \nfrom vdsm import libvirtconnection\nImportError:
cannot import name libvirtconnection\n',)../lib/vdsm/common/hooks.py:124:
HookError*


Thank you in advance!

Pavel
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/BK5OQC4LCB443NJZN2XJFF7VZB5UOH25/

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Martin Perina]

On Tue, Jun 11, 2019 at 6:53 PM Dafna Ron  wrote:

> Galit's patch should have solved it.
> Marcin, are you still failing?
>

I've just rebased https://gerrit.ovirt.org/100716 on top of Galit's change
so we should know within an hour or so ...


>
> On Tue, Jun 11, 2019 at 2:40 PM Eyal Edri  wrote:
>
>>
>>
>> On Tue, Jun 11, 2019 at 4:35 PM Marcin Sobczyk 
>> wrote:
>>
>>> Hi,
>>>
>>> basic suite fails for the patch with the following log:
>>>
>>>  
>>> [2019-06-11T11:34:26.175Z]
>>>- STDERR
>>>  
>>> [2019-06-11T11:34:26.175Z]
>>>  + yum -y install ovirt-host
>>>  
>>> [2019-06-11T11:34:26.175Z]
>>>  Error: Package: 32:bind-libs-9.9.4-74.el7_6.1.x86_64 (alocalsync)
>>>  
>>> [2019-06-11T11:34:26.175Z]
>>> Requires: bind-license = 32:9.9.4-74.el7_6.1
>>>  
>>> [2019-06-11T11:34:26.175Z]
>>> Installed: 32:bind-license-9.9.4-73.el7_6.noarch (installed)
>>>  
>>> [2019-06-11T11:34:26.175Z]
>>> bind-license = 32:9.9.4-73.el7_6
>>>
>>>
>> I think https://gerrit.ovirt.org/#/c/100691/ which was merged 2 hours
>> ago should address this issue.
>> Maybe other reposync files should be updated as well?
>>
>>
>>>  Seems unrelated and I'm having the same issue locally on my server.
>>> Dafna, do you have some insight regarding this dependency error?
>>>
>>> Thanks, Marcin
>>> On 6/11/19 1:15 PM, Martin Perina wrote:
>>>
>>>
>>>
>>> On Tue, Jun 11, 2019 at 11:58 AM Milan Zamazal 
>>> wrote:
>>>
 Dafna Ron  writes:

 > Hi,
 >
 > Please note vdsm has been broken since Fri the 7th
 >
 > to summarize again,  vdsm has a patch to remove sos plugin which is
 what
 > metrics is using in its ost tests
 > due to that, vdsm is failing the metrics tests and in order to solve
 it we
 > need to make a choice:
 > 1. fix the metrics tests to not use sos
 > 2. disable the metrics tests
 > 3. revert the sos patch until a decision is made on ^^

 #3 is not an option, it would make Vdsm uninstallable on newer RHEL
 versions.

>>>
>>> I've posted a patch https://gerrit.ovirt.org/100716 which is trying to
>>> install vdsm sos plugin if it's not installed either by vdsm nor sos.
>>> Currenlty waiting for CI, if run is successfull, I will extend the patch
>>> also for 4.3 basic suite.
>>>
>>>
 > Thanks,
 > Dafna
 >
 >
 > -- Forwarded message -
 > From: Dafna Ron 
 > Date: Mon, Jun 10, 2019 at 1:30 PM
 > Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [
 07-06-2019 ]
 > [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
 > To: Martin Perina , Milan Zamazal <
 mzama...@redhat.com>,
 > Shirly Radco 
 > Cc: devel , infra 
 >
 >
 > Shirly? any update on this?
 >
 > On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:
 >
 >> Hi,
 >>
 >> We have a failure in vdsm project on master.
 >>
 >> The issue is change:
 >> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
 >>
 >> which is failing on metrics as metrics is calling sos-logcollector.
 >>
 >> The patch cannot be changed as until centos 7.7 when sos-3.7-3, which
 >> contains vdsm plugin will come out.
 >> so until then, we are left with no sos plugin, which is causing the
 >> metrics test to fail.
 >>
 >> Shirly, can you please take a look and see if we can change the test
 to
 >> not call sos-logcollector?
 >> Please note, that we are expecting 4.3 to fail on same issue very
 soon.
 >>
 >> failed job can be found here:
 >>
 >>
 https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
 >>
 >>
 >> ERROR from test:
 >>
 >> lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine
 errors:
 >>  ERROR: Failed to get a sosreport from:
 lago-basic-suite-master-host-1; Could not pa

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Nir Soffer]

On Tue, Jun 11, 2019 at 12:24 PM Dafna Ron  wrote:

> Hi,
>
> Please note vdsm has been broken since Fri the 7th
>
> to summarize again,  vdsm has a patch to remove sos plugin which is what
> metrics is using in its ost tests
> due to that, vdsm is failing the metrics tests and in order to solve it we
> need to make a choice:
> 1. fix the metrics tests to not use sos
> 2. disable the metrics tests
> 3. revert the sos patch until a decision is made on ^^
>

Vdsm does not have sos plugin any more, so metrics need to change
to use upstream sos project.

until metrics is updated the tests using sos should be disabled or modified
to remove sos dependency.


>
> Thanks,
> Dafna
>
>
> -- Forwarded message -
> From: Dafna Ron 
> Date: Mon, Jun 10, 2019 at 1:30 PM
> Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [ 07-06-2019 ]
> [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
> To: Martin Perina , Milan Zamazal ,
> Shirly Radco 
> Cc: devel , infra 
>
>
> Shirly? any update on this?
>
> On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:
>
>> Hi,
>>
>> We have a failure in vdsm project on master.
>>
>> The issue is change:
>> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
>>
>> which is failing on metrics as metrics is calling sos-logcollector.
>>
>> The patch cannot be changed as until centos 7.7 when sos-3.7-3, which
>> contains vdsm plugin will come out.
>> so until then, we are left with no sos plugin, which is causing the
>> metrics test to fail.
>>
>> Shirly, can you please take a look and see if we can change the test to
>> not call sos-logcollector?
>> Please note, that we are expecting 4.3 to fail on same issue very soon.
>>
>> failed job can be found here:
>>
>> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
>>
>>
>> ERROR from test:
>>
>> lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine  errors:
>>  ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-1; 
>> Could not parse sosreport output
>> ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-0; Could 
>> not parse sosreport output
>>
>> lago.utils: DEBUG: Error while running thread Thread-3
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in 
>> _ret_via_queue
>> queue.put({'return': func()})
>>   File 
>> "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py",
>>  line 97, in run_log_collector
>> 'log collector failed. Exit code is %s' % result.code
>>   File "/usr/lib64/python2.7/unittest/case.py", line 462, in assertTrue
>> raise self.failureException(msg)
>> AssertionError: log collector failed. Exit code is 1
>> - >> end captured logging << --
>>
>> Thanks,
>> Dafna
>>
> ___
> Infra mailing list -- in...@ovirt.org
> To unsubscribe send an email to infra-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/E2UBWXYAE73XJ6I75N4ESXUFDIVMSIIS/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/LXIJDIASKFA47OVUP3QM3YPMYYO375S6/

[ovirt-devel] Re: Failed to add fedora-29 host to oVirt

[Sandro Bonazzola]

Il giorno mar 11 giu 2019 alle ore 11:15 Eyal Shenitzky 
ha scritto:

> Hi,
>
> I am trying to add fedora-29 host to me oVirt setup and failed due to the
> following error (from the engine log):
>
> 2019-06-11 11:24:59,123+03 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An
> error has occurred during installation of Host fedora_29: DNF   Problem:
> conflicting requests   - package
> ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires
> ovirt-hosted-engine-setup, but none of the providers can be installed   -
> package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
> does not have a compatible architecture   - nothing provides
> ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29
> needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>   - nothing provides vdsm-python >= 4.30 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>   - nothing provides glusterfs-cli >= 5.6 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>   - nothing provides vdsm-python >= 4.40.0 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch.
> 2019-06-11 11:24:59,133+03 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An
> error has occurred during installation of Host fedora_29: Failed to execute
> stage 'Package installation':   Problem: conflicting requests   - package
> ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires
> ovirt-hosted-engine-setup, but none of the providers can be installed   -
> package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
> does not have a compatible architecture   - nothing provides
> ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29
> needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>   - nothing provides vdsm-python >= 4.30 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
>   - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>   - nothing provides glusterfs-cli >= 5.6 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
>   - nothing provides vdsm-python >= 4.40.0 needed by
> ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch.
>
> When I try to install VDSM manually before adding the host the setup it
> installed the following version:  vdsm-4.18.999-447.git0bb7717.fc28.x86_64
>
>
> Any suggestions?
>

fix vdsm build on fc29 :-)
currently fc29 build for vdsm is not happening, I pushed a few patches
helping getting it working but definitely more help is needed to get it
working on fc29.



>
> --
> Regards,
> Eyal Shenitzky
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7FXMS3A22OSHR3GWQNT7IFANW6QXB7RY/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA 

sbona...@redhat.com

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/QEZU6BQ2EQPOBTCKMXOGENJFGR25TV3P/

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Dafna Ron]

Galit's patch should have solved it.
Marcin, are you still failing?


On Tue, Jun 11, 2019 at 2:40 PM Eyal Edri  wrote:

>
>
> On Tue, Jun 11, 2019 at 4:35 PM Marcin Sobczyk 
> wrote:
>
>> Hi,
>>
>> basic suite fails for the patch with the following log:
>>
>>  
>> [2019-06-11T11:34:26.175Z]
>>- STDERR
>>  
>> [2019-06-11T11:34:26.175Z]
>>  + yum -y install ovirt-host
>>  
>> [2019-06-11T11:34:26.175Z]
>>  Error: Package: 32:bind-libs-9.9.4-74.el7_6.1.x86_64 (alocalsync)
>>  
>> [2019-06-11T11:34:26.175Z]
>> Requires: bind-license = 32:9.9.4-74.el7_6.1
>>  
>> [2019-06-11T11:34:26.175Z]
>> Installed: 32:bind-license-9.9.4-73.el7_6.noarch (installed)
>>  
>> [2019-06-11T11:34:26.175Z]
>> bind-license = 32:9.9.4-73.el7_6
>>
>>
> I think https://gerrit.ovirt.org/#/c/100691/ which was merged 2 hours ago
> should address this issue.
> Maybe other reposync files should be updated as well?
>
>
>>  Seems unrelated and I'm having the same issue locally on my server.
>> Dafna, do you have some insight regarding this dependency error?
>>
>> Thanks, Marcin
>> On 6/11/19 1:15 PM, Martin Perina wrote:
>>
>>
>>
>> On Tue, Jun 11, 2019 at 11:58 AM Milan Zamazal 
>> wrote:
>>
>>> Dafna Ron  writes:
>>>
>>> > Hi,
>>> >
>>> > Please note vdsm has been broken since Fri the 7th
>>> >
>>> > to summarize again,  vdsm has a patch to remove sos plugin which is
>>> what
>>> > metrics is using in its ost tests
>>> > due to that, vdsm is failing the metrics tests and in order to solve
>>> it we
>>> > need to make a choice:
>>> > 1. fix the metrics tests to not use sos
>>> > 2. disable the metrics tests
>>> > 3. revert the sos patch until a decision is made on ^^
>>>
>>> #3 is not an option, it would make Vdsm uninstallable on newer RHEL
>>> versions.
>>>
>>
>> I've posted a patch https://gerrit.ovirt.org/100716 which is trying to
>> install vdsm sos plugin if it's not installed either by vdsm nor sos.
>> Currenlty waiting for CI, if run is successfull, I will extend the patch
>> also for 4.3 basic suite.
>>
>>
>>> > Thanks,
>>> > Dafna
>>> >
>>> >
>>> > -- Forwarded message -
>>> > From: Dafna Ron 
>>> > Date: Mon, Jun 10, 2019 at 1:30 PM
>>> > Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [
>>> 07-06-2019 ]
>>> > [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
>>> > To: Martin Perina , Milan Zamazal <
>>> mzama...@redhat.com>,
>>> > Shirly Radco 
>>> > Cc: devel , infra 
>>> >
>>> >
>>> > Shirly? any update on this?
>>> >
>>> > On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> We have a failure in vdsm project on master.
>>> >>
>>> >> The issue is change:
>>> >> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
>>> >>
>>> >> which is failing on metrics as metrics is calling sos-logcollector.
>>> >>
>>> >> The patch cannot be changed as until centos 7.7 when sos-3.7-3, which
>>> >> contains vdsm plugin will come out.
>>> >> so until then, we are left with no sos plugin, which is causing the
>>> >> metrics test to fail.
>>> >>
>>> >> Shirly, can you please take a look and see if we can change the test
>>> to
>>> >> not call sos-logcollector?
>>> >> Please note, that we are expecting 4.3 to fail on same issue very
>>> soon.
>>> >>
>>> >> failed job can be found here:
>>> >>
>>> >> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
>>> >>
>>> >>
>>> >> ERROR from test:
>>> >>
>>> >> lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine
>>> errors:
>>> >>  ERROR: Failed to get a sosreport from:
>>> lago-basic-suite-master-host-1; Could not parse sosreport output
>>> >> ERROR: Failed to get a sosreport from:
>>> lago-basic-suite-master-host-0; Could not parse sosreport output
>>> >>
>>> >> lago.utils: DEBUG: Error while running thread Thread-3
>>> >> Traceback (most recent call last):
>>> >>   File "/usr/lib/python2.7/site-packages/lago/utils.py

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Eyal Edri]

On Tue, Jun 11, 2019 at 4:35 PM Marcin Sobczyk  wrote:

> Hi,
>
> basic suite fails for the patch with the following log:
>
>  
> [2019-06-11T11:34:26.175Z]
>- STDERR
>  
> [2019-06-11T11:34:26.175Z]
>  + yum -y install ovirt-host
>  
> [2019-06-11T11:34:26.175Z]
>  Error: Package: 32:bind-libs-9.9.4-74.el7_6.1.x86_64 (alocalsync)
>  
> [2019-06-11T11:34:26.175Z]
> Requires: bind-license = 32:9.9.4-74.el7_6.1
>  
> [2019-06-11T11:34:26.175Z]
> Installed: 32:bind-license-9.9.4-73.el7_6.noarch (installed)
>  
> [2019-06-11T11:34:26.175Z]
> bind-license = 32:9.9.4-73.el7_6
>
>
I think https://gerrit.ovirt.org/#/c/100691/ which was merged 2 hours ago
should address this issue.
Maybe other reposync files should be updated as well?


>  Seems unrelated and I'm having the same issue locally on my server.
> Dafna, do you have some insight regarding this dependency error?
>
> Thanks, Marcin
> On 6/11/19 1:15 PM, Martin Perina wrote:
>
>
>
> On Tue, Jun 11, 2019 at 11:58 AM Milan Zamazal 
> wrote:
>
>> Dafna Ron  writes:
>>
>> > Hi,
>> >
>> > Please note vdsm has been broken since Fri the 7th
>> >
>> > to summarize again,  vdsm has a patch to remove sos plugin which is what
>> > metrics is using in its ost tests
>> > due to that, vdsm is failing the metrics tests and in order to solve it
>> we
>> > need to make a choice:
>> > 1. fix the metrics tests to not use sos
>> > 2. disable the metrics tests
>> > 3. revert the sos patch until a decision is made on ^^
>>
>> #3 is not an option, it would make Vdsm uninstallable on newer RHEL
>> versions.
>>
>
> I've posted a patch https://gerrit.ovirt.org/100716 which is trying to
> install vdsm sos plugin if it's not installed either by vdsm nor sos.
> Currenlty waiting for CI, if run is successfull, I will extend the patch
> also for 4.3 basic suite.
>
>
>> > Thanks,
>> > Dafna
>> >
>> >
>> > -- Forwarded message -
>> > From: Dafna Ron 
>> > Date: Mon, Jun 10, 2019 at 1:30 PM
>> > Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [
>> 07-06-2019 ]
>> > [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
>> > To: Martin Perina , Milan Zamazal <
>> mzama...@redhat.com>,
>> > Shirly Radco 
>> > Cc: devel , infra 
>> >
>> >
>> > Shirly? any update on this?
>> >
>> > On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:
>> >
>> >> Hi,
>> >>
>> >> We have a failure in vdsm project on master.
>> >>
>> >> The issue is change:
>> >> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
>> >>
>> >> which is failing on metrics as metrics is calling sos-logcollector.
>> >>
>> >> The patch cannot be changed as until centos 7.7 when sos-3.7-3, which
>> >> contains vdsm plugin will come out.
>> >> so until then, we are left with no sos plugin, which is causing the
>> >> metrics test to fail.
>> >>
>> >> Shirly, can you please take a look and see if we can change the test to
>> >> not call sos-logcollector?
>> >> Please note, that we are expecting 4.3 to fail on same issue very soon.
>> >>
>> >> failed job can be found here:
>> >>
>> >> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
>> >>
>> >>
>> >> ERROR from test:
>> >>
>> >> lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine
>> errors:
>> >>  ERROR: Failed to get a sosreport from:
>> lago-basic-suite-master-host-1; Could not parse sosreport output
>> >> ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-0;
>> Could not parse sosreport output
>> >>
>> >> lago.utils: DEBUG: Error while running thread Thread-3
>> >> Traceback (most recent call last):
>> >>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in
>> _ret_via_queue
>> >> queue.put({'return': func()})
>> >>   File
>> "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py",
>> line 97, in run_log_collector
>>

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Marcin Sobczyk]

Hi,

basic suite fails for the patch with the following log:

[2019-06-11T11:34:26.175Z] 
- STDERR
[2019-06-11T11:34:26.175Z] 
+ yum -y install ovirt-host
[2019-06-11T11:34:26.175Z] 
Error: Package: 32:bind-libs-9.9.4-74.el7_6.1.x86_64 (alocalsync)
[2019-06-11T11:34:26.175Z] 
Requires: bind-license = 32:9.9.4-74.el7_6.1
[2019-06-11T11:34:26.175Z] 
Installed: 32:bind-license-9.9.4-73.el7_6.noarch (installed)
[2019-06-11T11:34:26.175Z] 
bind-license = 32:9.9.4-73.el7_6


Seems unrelated and I'm having the same issue locally on my server.
Dafna, do you have some insight regarding this dependency error?

Thanks, Marcin

On 6/11/19 1:15 PM, Martin Perina wrote:



On Tue, Jun 11, 2019 at 11:58 AM Milan Zamazal > wrote:


Dafna Ron mailto:d...@redhat.com>> writes:

> Hi,
>
> Please note vdsm has been broken since Fri the 7th
>
> to summarize again,  vdsm has a patch to remove sos plugin which
is what
> metrics is using in its ost tests
> due to that, vdsm is failing the metrics tests and in order to
solve it we
> need to make a choice:
> 1. fix the metrics tests to not use sos
> 2. disable the metrics tests
> 3. revert the sos patch until a decision is made on ^^

#3 is not an option, it would make Vdsm uninstallable on newer RHEL
versions.


I've posted a patch https://gerrit.ovirt.org/100716 which is trying to 
install vdsm sos plugin if it's not installed either by vdsm nor sos.
Currenlty waiting for CI, if run is successfull, I will extend the 
patch also for 4.3 basic suite.



> Thanks,
> Dafna
>
>
> -- Forwarded message -
> From: Dafna Ron mailto:d...@redhat.com>>
> Date: Mon, Jun 10, 2019 at 1:30 PM
> Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [
07-06-2019 ]
> [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
> To: Martin Perina mailto:mper...@redhat.com>>, Milan Zamazal mailto:mzama...@redhat.com>>,
> Shirly Radco mailto:sra...@redhat.com>>
> Cc: devel mailto:devel@ovirt.org>>, infra
mailto:in...@ovirt.org>>
>
>
> Shirly? any update on this?
>
> On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron mailto:d...@redhat.com>> wrote:
>
>> Hi,
>>
>> We have a failure in vdsm project on master.
>>
>> The issue is change:
>> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
>>
>> which is failing on metrics as metrics is calling sos-logcollector.
>>
>> The patch cannot be changed as until centos 7.7 when sos-3.7-3,
which
>> contains vdsm plugin will come out.
>> so until then, we are left with no sos plugin, which is causing the
>> metrics test to fail.
>>
>> Shirly, can you please take a look and see if we can change the
test to
>> not call sos-logcollector?
>> Please note, that we are expecting 4.3 to fail on same issue
very soon.
>>
>> failed job can be found here:
>>
>>
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
>>
>>
>> ERROR from test:
>>
>> lago.ssh: DEBUG: Command 8626fe70 on
lago-basic-suite-master-engine  errors:
>>  ERROR: Failed to get a sosreport from:
lago-basic-suite-master-host-1; Could not parse sosreport output
>> ERROR: Failed to get a sosreport from:
lago-basic-suite-master-host-0; Could not parse sosreport output
>>
>> lago.utils: DEBUG: Error while running thread Thread-3
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line
58, in _ret_via_queue
>>     queue.put({'return': func()})
>>   File

"/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py",
line 97, in run_log_collector
>>     'log collector failed. Exit

[ovirt-devel] Re: GetDeviceList and direct LUNs

[Fedor Gavrilov]

There are couple of things that remain unclear to me.

What permission check it would make sense to do when updating sizes of direct 
LUNs?
At seems that the only thing, besides LUN Guids, needed to execute 
VDSCommandType.GetDeviceList is storage pool id (to get all VDS and pass them 
as an argument).
So it would make sense to return something like this in 
getPermissionCheckSubjects:
  new PermissionSubject(getStoragePoolId(), VdcObjectType.StoragePool, 
getActionType().getActionGroup()));
But it's unclear what storage pool we should pick. Direct LUNs don't seems to 
have much info associated with them, there is only storageDomainId we can 
retrieve by lunDao and then get related storagePoolIds I guess.
Is this the right way?

Thanks,
Fedor Gavrilov

- Original Message -
From: "Nir Soffer" 
To: "Fedor Gavrilov" 
Cc: "devel" , "Fred Rolland" 
Sent: Tuesday, June 11, 2019 11:08:36 AM
Subject: Re: [ovirt-devel] GetDeviceList and direct LUNs

On Tue, Jun 11, 2019, 12:04 Fedor Gavrilov  wrote:

> Hi Nir,
>
> Thanks a lot for the response!
>
> It could be that I misunderstand what you say, but I am not sure about if
> making one "Refresh all LUN sizes" button is better idea than one button
> per LUN.
>

Vdsm does not support refreshing single LUN. We refresh all LUNs in all
storage servers of any type. So global refresh command seems to be the
right way to go.


From what I learned from support, there are users with lots of LUNs per VM
> and huge amount of direct LUNs total. If someone resizes several LUNs at
> once, they are probably doing so from a script anyway and can make use of
> curl.
>
> Thanks,
> Fedor Gavrilov
>
> - Original Message -
> From: "Nir Soffer" 
> To: "Fedor Gavrilov" 
> Cc: "devel" , "Fred Rolland" 
> Sent: Monday, June 10, 2019 7:33:45 PM
> Subject: Re: [ovirt-devel] GetDeviceList and direct LUNs
>
> On Mon, Jun 10, 2019 at 6:20 PM Fedor Gavrilov 
> wrote:
>
> > Hi,
> >
> > I want to implement a feature that would allow one to manually refresh
> > sizes for direct LUNs and I am not sure if existing code in the engine
> > codebase is gonna help with that.
> >
> > RefreshLunsSizeCommand seems to be doing what is needed, but it operates
> > on a premise that LUNs to refresh belong to a storage domain which makes
> > most of its code irrelevant for purposes of direct LUNs.
> > It seems that workhorse is GetDeviceList command, but from the code I
> > can't quite understand if it's supposed to be used with external iSCSI
> > targets. Especially 'VDS' part here confuses me since I am not sure what
> > VDS we're talking about in the first place when using direct LUN.
> >
> > If GetDeviceList is of no use, is there anything else VDSM provides?
> >
>
> On vdsm side, you want to use Host.getDeviceList:
>
> https://github.com/oVirt/vdsm/blob/2bce8e8bff09b9c2fe4854ad91c40fdf6b7a01e1/lib/vdsm/api/vdsm-api.yml#L8366
>
> Specify the storage type and the WWN of the LUN, also knows as GUID in
> vdsm/engine.
>
> checkStatus must be False, it is needed only when adding a device to a VG.
>
> The resize is performed in sdCache.refreshStorage(), effecting all storage
> types and all devices, so you
> want to call Host.getDeviceList() once with the list of GUIDs to refresh,
> instead of once per GUID.
>
> Adding Fred who worked on this feature.
>
> Nir
>
>
> >
> > Thanks,
> > Fedor Gavrilov
> > ___
> > Devel mailing list -- devel@ovirt.org
> > To unsubscribe send an email to devel-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct:
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> >
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NOJ2UT6FP5VRTVFFZNMMB2JYNE25TIMQ/
> >
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/A46S62NJCBUW4P2IDYAH24T46OHD6RTZ/

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Martin Perina]

On Tue, Jun 11, 2019 at 11:58 AM Milan Zamazal  wrote:

> Dafna Ron  writes:
>
> > Hi,
> >
> > Please note vdsm has been broken since Fri the 7th
> >
> > to summarize again,  vdsm has a patch to remove sos plugin which is what
> > metrics is using in its ost tests
> > due to that, vdsm is failing the metrics tests and in order to solve it
> we
> > need to make a choice:
> > 1. fix the metrics tests to not use sos
> > 2. disable the metrics tests
> > 3. revert the sos patch until a decision is made on ^^
>
> #3 is not an option, it would make Vdsm uninstallable on newer RHEL
> versions.
>

I've posted a patch https://gerrit.ovirt.org/100716 which is trying to
install vdsm sos plugin if it's not installed either by vdsm nor sos.
Currenlty waiting for CI, if run is successfull, I will extend the patch
also for 4.3 basic suite.


> > Thanks,
> > Dafna
> >
> >
> > -- Forwarded message -
> > From: Dafna Ron 
> > Date: Mon, Jun 10, 2019 at 1:30 PM
> > Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [ 07-06-2019
> ]
> > [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
> > To: Martin Perina , Milan Zamazal <
> mzama...@redhat.com>,
> > Shirly Radco 
> > Cc: devel , infra 
> >
> >
> > Shirly? any update on this?
> >
> > On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:
> >
> >> Hi,
> >>
> >> We have a failure in vdsm project on master.
> >>
> >> The issue is change:
> >> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
> >>
> >> which is failing on metrics as metrics is calling sos-logcollector.
> >>
> >> The patch cannot be changed as until centos 7.7 when sos-3.7-3, which
> >> contains vdsm plugin will come out.
> >> so until then, we are left with no sos plugin, which is causing the
> >> metrics test to fail.
> >>
> >> Shirly, can you please take a look and see if we can change the test to
> >> not call sos-logcollector?
> >> Please note, that we are expecting 4.3 to fail on same issue very soon.
> >>
> >> failed job can be found here:
> >>
> >> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
> >>
> >>
> >> ERROR from test:
> >>
> >> lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine
> errors:
> >>  ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-1;
> Could not parse sosreport output
> >> ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-0;
> Could not parse sosreport output
> >>
> >> lago.utils: DEBUG: Error while running thread Thread-3
> >> Traceback (most recent call last):
> >>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in
> _ret_via_queue
> >> queue.put({'return': func()})
> >>   File
> "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py",
> line 97, in run_log_collector
> >> 'log collector failed. Exit code is %s' % result.code
> >>   File "/usr/lib64/python2.7/unittest/case.py", line 462, in assertTrue
> >> raise self.failureException(msg)
> >> AssertionError: log collector failed. Exit code is 1
> >> - >> end captured logging << --
> >>
> >> Thanks,
> >> Dafna
> >>
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/SQJDJHHQR52QTGRZBIOLBWWVGUX3ZPNW/

[ovirt-devel] Re: [urgent] vdsm broken since Friday (failing CQ)

[Milan Zamazal]

Dafna Ron  writes:

> Hi,
>
> Please note vdsm has been broken since Fri the 7th
>
> to summarize again,  vdsm has a patch to remove sos plugin which is what
> metrics is using in its ost tests
> due to that, vdsm is failing the metrics tests and in order to solve it we
> need to make a choice:
> 1. fix the metrics tests to not use sos
> 2. disable the metrics tests
> 3. revert the sos patch until a decision is made on ^^

#3 is not an option, it would make Vdsm uninstallable on newer RHEL
versions.

> Thanks,
> Dafna
>
>
> -- Forwarded message -
> From: Dafna Ron 
> Date: Mon, Jun 10, 2019 at 1:30 PM
> Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [ 07-06-2019 ]
> [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
> To: Martin Perina , Milan Zamazal ,
> Shirly Radco 
> Cc: devel , infra 
>
>
> Shirly? any update on this?
>
> On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:
>
>> Hi,
>>
>> We have a failure in vdsm project on master.
>>
>> The issue is change:
>> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
>>
>> which is failing on metrics as metrics is calling sos-logcollector.
>>
>> The patch cannot be changed as until centos 7.7 when sos-3.7-3, which
>> contains vdsm plugin will come out.
>> so until then, we are left with no sos plugin, which is causing the
>> metrics test to fail.
>>
>> Shirly, can you please take a look and see if we can change the test to
>> not call sos-logcollector?
>> Please note, that we are expecting 4.3 to fail on same issue very soon.
>>
>> failed job can be found here:
>>
>> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
>>
>>
>> ERROR from test:
>>
>> lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine  errors:
>>  ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-1; 
>> Could not parse sosreport output
>> ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-0; Could 
>> not parse sosreport output
>>
>> lago.utils: DEBUG: Error while running thread Thread-3
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in 
>> _ret_via_queue
>> queue.put({'return': func()})
>>   File 
>> "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py",
>>  line 97, in run_log_collector
>> 'log collector failed. Exit code is %s' % result.code
>>   File "/usr/lib64/python2.7/unittest/case.py", line 462, in assertTrue
>> raise self.failureException(msg)
>> AssertionError: log collector failed. Exit code is 1
>> - >> end captured logging << --
>>
>> Thanks,
>> Dafna
>>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/PYZVKCUOMEIQKFY7T2XM7SPLHVMI7NKU/

[ovirt-devel] Re: vdsm has been tagged (v4.30.19)

[Dafna Ron]

note that vdsm has been failing in CQ since Friday and have not passed CQ.


On Tue, Jun 11, 2019 at 10:44 AM Milan Zamazal  wrote:

>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/5FSD24HBSB6N7CL3UIXIZSA5HUCVDOA7/

[ovirt-devel] vdsm has been tagged (v4.30.19)

[Milan Zamazal]

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/RECZPIXF5BXWZWGYXGYIQYG55HNCHFHK/

[ovirt-devel] Re: GetDeviceList and direct LUNs

[Fedor Gavrilov]

I see. Well, since we're not doing this automatically I guess there is not much 
harm.

Thanks,
Fedor Gavrilov

- Original Message -
From: "Nir Soffer" 
To: "Fedor Gavrilov" 
Cc: "devel" , "Fred Rolland" 
Sent: Tuesday, June 11, 2019 11:08:36 AM
Subject: Re: [ovirt-devel] GetDeviceList and direct LUNs

On Tue, Jun 11, 2019, 12:04 Fedor Gavrilov  wrote:

> Hi Nir,
>
> Thanks a lot for the response!
>
> It could be that I misunderstand what you say, but I am not sure about if
> making one "Refresh all LUN sizes" button is better idea than one button
> per LUN.
>

Vdsm does not support refreshing single LUN. We refresh all LUNs in all
storage servers of any type. So global refresh command seems to be the
right way to go.


From what I learned from support, there are users with lots of LUNs per VM
> and huge amount of direct LUNs total. If someone resizes several LUNs at
> once, they are probably doing so from a script anyway and can make use of
> curl.
>
> Thanks,
> Fedor Gavrilov
>
> - Original Message -
> From: "Nir Soffer" 
> To: "Fedor Gavrilov" 
> Cc: "devel" , "Fred Rolland" 
> Sent: Monday, June 10, 2019 7:33:45 PM
> Subject: Re: [ovirt-devel] GetDeviceList and direct LUNs
>
> On Mon, Jun 10, 2019 at 6:20 PM Fedor Gavrilov 
> wrote:
>
> > Hi,
> >
> > I want to implement a feature that would allow one to manually refresh
> > sizes for direct LUNs and I am not sure if existing code in the engine
> > codebase is gonna help with that.
> >
> > RefreshLunsSizeCommand seems to be doing what is needed, but it operates
> > on a premise that LUNs to refresh belong to a storage domain which makes
> > most of its code irrelevant for purposes of direct LUNs.
> > It seems that workhorse is GetDeviceList command, but from the code I
> > can't quite understand if it's supposed to be used with external iSCSI
> > targets. Especially 'VDS' part here confuses me since I am not sure what
> > VDS we're talking about in the first place when using direct LUN.
> >
> > If GetDeviceList is of no use, is there anything else VDSM provides?
> >
>
> On vdsm side, you want to use Host.getDeviceList:
>
> https://github.com/oVirt/vdsm/blob/2bce8e8bff09b9c2fe4854ad91c40fdf6b7a01e1/lib/vdsm/api/vdsm-api.yml#L8366
>
> Specify the storage type and the WWN of the LUN, also knows as GUID in
> vdsm/engine.
>
> checkStatus must be False, it is needed only when adding a device to a VG.
>
> The resize is performed in sdCache.refreshStorage(), effecting all storage
> types and all devices, so you
> want to call Host.getDeviceList() once with the list of GUIDs to refresh,
> instead of once per GUID.
>
> Adding Fred who worked on this feature.
>
> Nir
>
>
> >
> > Thanks,
> > Fedor Gavrilov
> > ___
> > Devel mailing list -- devel@ovirt.org
> > To unsubscribe send an email to devel-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct:
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> >
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NOJ2UT6FP5VRTVFFZNMMB2JYNE25TIMQ/
> >
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/J2NO3SHE2G5UOI3JKKMTJAQRSKNJBEJN/

[ovirt-devel] Re: GetDeviceList and direct LUNs

[Nir Soffer]

On Tue, Jun 11, 2019, 12:04 Fedor Gavrilov  wrote:

> Hi Nir,
>
> Thanks a lot for the response!
>
> It could be that I misunderstand what you say, but I am not sure about if
> making one "Refresh all LUN sizes" button is better idea than one button
> per LUN.
>

Vdsm does not support refreshing single LUN. We refresh all LUNs in all
storage servers of any type. So global refresh command seems to be the
right way to go.


>From what I learned from support, there are users with lots of LUNs per VM
> and huge amount of direct LUNs total. If someone resizes several LUNs at
> once, they are probably doing so from a script anyway and can make use of
> curl.
>
> Thanks,
> Fedor Gavrilov
>
> - Original Message -
> From: "Nir Soffer" 
> To: "Fedor Gavrilov" 
> Cc: "devel" , "Fred Rolland" 
> Sent: Monday, June 10, 2019 7:33:45 PM
> Subject: Re: [ovirt-devel] GetDeviceList and direct LUNs
>
> On Mon, Jun 10, 2019 at 6:20 PM Fedor Gavrilov 
> wrote:
>
> > Hi,
> >
> > I want to implement a feature that would allow one to manually refresh
> > sizes for direct LUNs and I am not sure if existing code in the engine
> > codebase is gonna help with that.
> >
> > RefreshLunsSizeCommand seems to be doing what is needed, but it operates
> > on a premise that LUNs to refresh belong to a storage domain which makes
> > most of its code irrelevant for purposes of direct LUNs.
> > It seems that workhorse is GetDeviceList command, but from the code I
> > can't quite understand if it's supposed to be used with external iSCSI
> > targets. Especially 'VDS' part here confuses me since I am not sure what
> > VDS we're talking about in the first place when using direct LUN.
> >
> > If GetDeviceList is of no use, is there anything else VDSM provides?
> >
>
> On vdsm side, you want to use Host.getDeviceList:
>
> https://github.com/oVirt/vdsm/blob/2bce8e8bff09b9c2fe4854ad91c40fdf6b7a01e1/lib/vdsm/api/vdsm-api.yml#L8366
>
> Specify the storage type and the WWN of the LUN, also knows as GUID in
> vdsm/engine.
>
> checkStatus must be False, it is needed only when adding a device to a VG.
>
> The resize is performed in sdCache.refreshStorage(), effecting all storage
> types and all devices, so you
> want to call Host.getDeviceList() once with the list of GUIDs to refresh,
> instead of once per GUID.
>
> Adding Fred who worked on this feature.
>
> Nir
>
>
> >
> > Thanks,
> > Fedor Gavrilov
> > ___
> > Devel mailing list -- devel@ovirt.org
> > To unsubscribe send an email to devel-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct:
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> >
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NOJ2UT6FP5VRTVFFZNMMB2JYNE25TIMQ/
> >
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/RSGIIUAF3LGCYC5LDEBUR5Z7UA2CNPYZ/

[ovirt-devel] Re: GetDeviceList and direct LUNs

[Fedor Gavrilov]

Hi Nir,

Thanks a lot for the response!

It could be that I misunderstand what you say, but I am not sure about if 
making one "Refresh all LUN sizes" button is better idea than one button per 
LUN. 
From what I learned from support, there are users with lots of LUNs per VM and 
huge amount of direct LUNs total. If someone resizes several LUNs at once, they 
are probably doing so from a script anyway and can make use of curl.

Thanks,
Fedor Gavrilov

- Original Message -
From: "Nir Soffer" 
To: "Fedor Gavrilov" 
Cc: "devel" , "Fred Rolland" 
Sent: Monday, June 10, 2019 7:33:45 PM
Subject: Re: [ovirt-devel] GetDeviceList and direct LUNs

On Mon, Jun 10, 2019 at 6:20 PM Fedor Gavrilov  wrote:

> Hi,
>
> I want to implement a feature that would allow one to manually refresh
> sizes for direct LUNs and I am not sure if existing code in the engine
> codebase is gonna help with that.
>
> RefreshLunsSizeCommand seems to be doing what is needed, but it operates
> on a premise that LUNs to refresh belong to a storage domain which makes
> most of its code irrelevant for purposes of direct LUNs.
> It seems that workhorse is GetDeviceList command, but from the code I
> can't quite understand if it's supposed to be used with external iSCSI
> targets. Especially 'VDS' part here confuses me since I am not sure what
> VDS we're talking about in the first place when using direct LUN.
>
> If GetDeviceList is of no use, is there anything else VDSM provides?
>

On vdsm side, you want to use Host.getDeviceList:
https://github.com/oVirt/vdsm/blob/2bce8e8bff09b9c2fe4854ad91c40fdf6b7a01e1/lib/vdsm/api/vdsm-api.yml#L8366

Specify the storage type and the WWN of the LUN, also knows as GUID in
vdsm/engine.

checkStatus must be False, it is needed only when adding a device to a VG.

The resize is performed in sdCache.refreshStorage(), effecting all storage
types and all devices, so you
want to call Host.getDeviceList() once with the list of GUIDs to refresh,
instead of once per GUID.

Adding Fred who worked on this feature.

Nir


>
> Thanks,
> Fedor Gavrilov
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NOJ2UT6FP5VRTVFFZNMMB2JYNE25TIMQ/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/YDQDJBH6WPN4KRMRSELKXCUQZQ5PRUOQ/

[ovirt-devel] [urgent] vdsm broken since Friday (failing CQ)

[Dafna Ron]

Hi,

Please note vdsm has been broken since Fri the 7th

to summarize again,  vdsm has a patch to remove sos plugin which is what
metrics is using in its ost tests
due to that, vdsm is failing the metrics tests and in order to solve it we
need to make a choice:
1. fix the metrics tests to not use sos
2. disable the metrics tests
3. revert the sos patch until a decision is made on ^^

Thanks,
Dafna


-- Forwarded message -
From: Dafna Ron 
Date: Mon, Jun 10, 2019 at 1:30 PM
Subject: Re: [ OST Failure Report ] [ oVirt Master (vdsm) ] [ 07-06-2019 ]
[ 003_00_metrics_bootstrap.metrics_and_log_collector ]
To: Martin Perina , Milan Zamazal ,
Shirly Radco 
Cc: devel , infra 


Shirly? any update on this?

On Fri, Jun 7, 2019 at 11:54 AM Dafna Ron  wrote:

> Hi,
>
> We have a failure in vdsm project on master.
>
> The issue is change:
> https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin
>
> which is failing on metrics as metrics is calling sos-logcollector.
>
> The patch cannot be changed as until centos 7.7 when sos-3.7-3, which
> contains vdsm plugin will come out.
> so until then, we are left with no sos plugin, which is causing the
> metrics test to fail.
>
> Shirly, can you please take a look and see if we can change the test to
> not call sos-logcollector?
> Please note, that we are expecting 4.3 to fail on same issue very soon.
>
> failed job can be found here:
>
> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/
>
>
> ERROR from test:
>
> lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine  errors:
>  ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-1; Could 
> not parse sosreport output
> ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-0; Could 
> not parse sosreport output
>
> lago.utils: DEBUG: Error while running thread Thread-3
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in 
> _ret_via_queue
> queue.put({'return': func()})
>   File 
> "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py",
>  line 97, in run_log_collector
> 'log collector failed. Exit code is %s' % result.code
>   File "/usr/lib64/python2.7/unittest/case.py", line 462, in assertTrue
> raise self.failureException(msg)
> AssertionError: log collector failed. Exit code is 1
> - >> end captured logging << --
>
> Thanks,
> Dafna
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/E2UBWXYAE73XJ6I75N4ESXUFDIVMSIIS/

[ovirt-devel] Failed to add fedora-29 host to oVirt

[Eyal Shenitzky]

Hi,

I am trying to add fedora-29 host to me oVirt setup and failed due to the
following error (from the engine log):

2019-06-11 11:24:59,123+03 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An
error has occurred during installation of Host fedora_29: DNF   Problem:
conflicting requests   - package
ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires
ovirt-hosted-engine-setup, but none of the providers can be installed   -
package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
does not have a compatible architecture   - nothing provides
ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29
needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
  - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
  - nothing provides vdsm-python >= 4.30 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
  - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
  - nothing provides glusterfs-cli >= 5.6 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
  - nothing provides vdsm-python >= 4.40.0 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch.
2019-06-11 11:24:59,133+03 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An
error has occurred during installation of Host fedora_29: Failed to execute
stage 'Package installation':   Problem: conflicting requests   - package
ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires
ovirt-hosted-engine-setup, but none of the providers can be installed   -
package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
does not have a compatible architecture   - nothing provides
ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29
needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x
  - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
  - nothing provides vdsm-python >= 4.30 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch
  - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
  - nothing provides glusterfs-cli >= 5.6 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch
  - nothing provides vdsm-python >= 4.40.0 needed by
ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch.

When I try to install VDSM manually before adding the host the setup it
installed the following version:  vdsm-4.18.999-447.git0bb7717.fc28.x86_64


Any suggestions?

-- 
Regards,
Eyal Shenitzky
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7FXMS3A22OSHR3GWQNT7IFANW6QXB7RY/

[ovirt-devel] vdsm has been tagged (v4.30.18)

[Milan Zamazal]

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/YMNU6RJ2QEZHTNPLFWWWUTT5JQ7WXK7H/

[ovirt-devel] ovirt-engine has been tagged (ovirt-engine-4.3.5)

[Tal Nisan]

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7VUG6236I5KAXUISQANBOLFW7ULG5IL4/