Re: [ovirt-devel] [ACTION REQUIRED] upgrade to Fedora 27 for otopi on master

[Eli Mesika]

I have upgraded to fc27
I am not able to add a host to a PPC cluster : "no otopi module ..."

otopi is installed

rpm -qa |grep otopi
otopi-java-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch
otopi-common-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch
python2-otopi-devtools-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch
python2-otopi-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch

Any ideas ?


On Wed, Feb 28, 2018 at 7:01 PM, Greg Sheremeta  wrote:

> [changing subject]
>
> Looks like we all have to upgrade Fedora devel machines to Fedora 27.
>
> Greg
>
> On Wed, Feb 28, 2018 at 11:05 AM, Yedidyah Bar David 
> wrote:
>
>> (Adding devel, was asked twice already)
>>
>> On Wed, Feb 28, 2018 at 4:52 PM, Eli Mesika  wrote:
>> > Hi Didi
>> >
>> > I am getting :
>> >
>> >
>> > ***L:ERROR Internal error: type object 'Stages' has no attribute
>> > 'ANSWER_FILE_GENERATED'
>> > Traceback (most recent call last):
>> >   File "/usr/lib/python2.7/site-packages/otopi/__main__.py", line 88,
>> in
>> > main
>> > installer.execute()
>> >   File "/usr/lib/python2.7/site-packages/otopi/main.py", line 153, in
>> > execute
>> > sys.exc_info()[2],
>> >   File "/usr/lib/python2.7/site-packages/otopi/util.py", line 81, in
>> > raiseExceptionInformation
>> > exec('raise info[1], None, info[2]')
>> >   File "/usr/lib/python2.7/site-packages/otopi/main.py", line 147, in
>> > execute
>> > self.context.loadPlugins()
>> >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 859,
>> in
>> > loadPlugins
>> > self._loadPluginGroups(plugindir, needgroups, loadedgroups)
>> >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 113,
>> in
>> > _loadPluginGroups
>> > self._loadPlugins(path, path, groupname)
>> >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, in
>> > _loadPlugins
>> > self._loadPlugins(base, d, groupname)
>> >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, in
>> > _loadPlugins
>> > self._loadPlugins(base, d, groupname)
>> >   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 101,
>> in
>> > _loadPlugins
>> > os.path.basename(path),
>> >   File "/usr/lib/python2.7/site-packages/otopi/util.py", line 105, in
>> > loadModule
>> > mod_desc
>> >   File
>> > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup
>> /bin/../plugins/ovirt-engine-common/base/core/__init__.py",
>> > line 24, in 
>> > from . import answerfile
>> >   File
>> > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup
>> /bin/../plugins/ovirt-engine-common/base/core/answerfile.py",
>> > line 38, in 
>> > class Plugin(plugin.PluginBase):
>> >   File
>> > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup
>> /bin/../plugins/ovirt-engine-common/base/core/answerfile.py",
>> > line 60, in Plugin
>> > otopicons.Stages.ANSWER_FILE_GENERATED,
>> > PluginLoadException: type object 'Stages' has no attribute
>> > 'ANSWER_FILE_GENERATED'
>> >
>>
>> Please update otopi.
>>
>> If you are on fedora, you'll need to upgrade to fc27 first.
>>
>> Good luck,
>> --
>> Didi
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] FC27 updates broken for ovirt-4.2

[Cole Robinson]

On 03/01/2018 09:49 AM, Viktor Mihajlovski wrote:
> On 28.02.2018 17:27, Cole Robinson wrote:
>> On 02/28/2018 03:39 AM, Dan Horák wrote:
>>> On Tue, 27 Feb 2018 16:26:28 -0500
>>> Cole Robinson  wrote:
>>>
 On 02/27/2018 08:03 AM, Dan Horák wrote:
> On Tue, 27 Feb 2018 13:54:06 +0100
> Viktor Mihajlovski  wrote:
>
>> On 27.02.2018 13:35, Nir Soffer wrote:
>>> בתאריך יום ג׳, 27 בפבר׳ 2018, 13:25, מאת Dan Horák
>>>  ‏:
>>>
 On Tue, 27 Feb 2018 10:13:15 +0100
 Viktor Mihajlovski  wrote:

> On 27.02.2018 01:26, Nir Soffer wrote:
>> בתאריך יום ב׳, 26 בפבר׳ 2018, 22:10, מאת Yaniv Kaul
>>  ‏:
>>
>>> On Mon, Feb 26, 2018 at 7:17 PM, Viktor Mihajlovski <
>>> mihaj...@linux.vnet.ibm.com> wrote:
>>>
 I just tried to update the ovirt packages on my FC27 host,
 but failed due to https://gerrit.ovirt.org/#/c/87628/

 vdsm now requires libvirt >= 3.10.0-132 but Fedora 27 has
 only 3.7.0-4 the moment.

 It's generic Fedora 27, but since I run on s390,
 cross-posting to s390 list.

 I guess there's good reason to require libvirt 3.10. Is there
 any chance that we can get libvirt updated for Fedora 27?

>>>
>>> Perhaps use the virt-preview[1] repo for now?
>>>
>>
>> Yes, we require virt-preview for Fedora. This is why that patch
>> did not fail in the CI.
> Makes sense, unfortunately virt-preview doesn't contains s390
> binaries at this point in time. Would be great if at least
> libvirt and qemu could be built for s390.

 looks like it's even x86_64 only, /me wonders what it would
 require to offer other arches (aarch64, ppc64le, s390x) as well

>>>
>>> If we need to support platform not supported in virt-preview, we
>>> need to chage the requirement so it is used only on x86_64.
>>>
>>> Victor, would you like to send a patch?
>> I believe there was a good reason to bump the libvirt requirement
>> in the vdsm package (some bugfix). Ideally, virt-preview should be
>> build for s390 as well.
>> If I'm not mistaking, the script
>> https://github.com/crobinso/build-fedora-virt-preview is used to
>> build the RPMs and populate the repository.
>>
>> Dan, Cole: what would it take to run this on the fedora-390 build
>> machine?
>
> after a brief look the script needs to be made multi-arch-aware (it
> hard-codes x86_64 in some places), when it calls mock, and then it
> needs some HW (we have ppc64le and s390x even now, aarch64 might
> take a while), overall it looks doable to me. Cole, what do you
> think?
>

 I'm open to the idea in theory but in practice right now the script
 uses mock locally so it's basically tied to the one build machine I
 use which is x86. I have arm32 and aarch64 hardware locally but TBH I
 have very little interest in running a build farm and dealing with
 all the issues of connecting to remote machines, pulling down build
 output, etc. In fact I've been meaning to move virt-preview to copr
 for a long while which is going to tie it even deeper to x86, this
 would make virt-preview easier to enable and let me scrap much of my
 custom code for building/uploading repo contents.
>>>
>>> copr would give us ppc64le and probably aarch64 too in addition to x86,
>>> but can't help with s390. We already have build infra internally
>>> covering all arches driven by Jenkins, with plans to move the workloads
>>> to CentOS infra. I'll look whether or how it could be used for
>>> multi-arch virt-preview repos. 
>>>
 We could re-implement it using koji scratch builds which have multiple
 arch support nowadays but I did that in the past for x86 and I recall
 feeling it was quite brittle, though I don't remember the details,
 maybe it was just my implementation.
>>>
>>> I suspect the problem with koji scratch builds in this case is that
>>> they can't be used in buildroots, which the virt-preview stack requires.
>>>
>>
>> Good point, but generally virt-preview packages are very loosely coupled
>> and don't have strong version dependencies on one another. Occasionally
>> a small dependency needs to be updated like libiscsi or libcacard but in
>> fact it's been a long time since that's been required.
>>
>> - Cole
>>
> Hi Cole, for the time being I've patched vdsm to require libvirt 3.7.0-4
> (which contains the hotplug patch required by vdsm). Unfortunately, this
> release is still only in updates-testing, which lead to a build failure
> on ovirt Jenkins.
> Do you have an idea by when 3.7.0-4 will be propagated to fedora 

Re: [ovirt-devel] FC27 updates broken for ovirt-4.2

[Viktor Mihajlovski]

On 28.02.2018 17:27, Cole Robinson wrote:
> On 02/28/2018 03:39 AM, Dan Horák wrote:
>> On Tue, 27 Feb 2018 16:26:28 -0500
>> Cole Robinson  wrote:
>>
>>> On 02/27/2018 08:03 AM, Dan Horák wrote:
 On Tue, 27 Feb 2018 13:54:06 +0100
 Viktor Mihajlovski  wrote:

> On 27.02.2018 13:35, Nir Soffer wrote:
>> בתאריך יום ג׳, 27 בפבר׳ 2018, 13:25, מאת Dan Horák
>>  ‏:
>>
>>> On Tue, 27 Feb 2018 10:13:15 +0100
>>> Viktor Mihajlovski  wrote:
>>>
 On 27.02.2018 01:26, Nir Soffer wrote:
> בתאריך יום ב׳, 26 בפבר׳ 2018, 22:10, מאת Yaniv Kaul
>  ‏:
>
>> On Mon, Feb 26, 2018 at 7:17 PM, Viktor Mihajlovski <
>> mihaj...@linux.vnet.ibm.com> wrote:
>>
>>> I just tried to update the ovirt packages on my FC27 host,
>>> but failed due to https://gerrit.ovirt.org/#/c/87628/
>>>
>>> vdsm now requires libvirt >= 3.10.0-132 but Fedora 27 has
>>> only 3.7.0-4 the moment.
>>>
>>> It's generic Fedora 27, but since I run on s390,
>>> cross-posting to s390 list.
>>>
>>> I guess there's good reason to require libvirt 3.10. Is there
>>> any chance that we can get libvirt updated for Fedora 27?
>>>
>>
>> Perhaps use the virt-preview[1] repo for now?
>>
>
> Yes, we require virt-preview for Fedora. This is why that patch
> did not fail in the CI.
 Makes sense, unfortunately virt-preview doesn't contains s390
 binaries at this point in time. Would be great if at least
 libvirt and qemu could be built for s390.
>>>
>>> looks like it's even x86_64 only, /me wonders what it would
>>> require to offer other arches (aarch64, ppc64le, s390x) as well
>>>
>>
>> If we need to support platform not supported in virt-preview, we
>> need to chage the requirement so it is used only on x86_64.
>>
>> Victor, would you like to send a patch?
> I believe there was a good reason to bump the libvirt requirement
> in the vdsm package (some bugfix). Ideally, virt-preview should be
> build for s390 as well.
> If I'm not mistaking, the script
> https://github.com/crobinso/build-fedora-virt-preview is used to
> build the RPMs and populate the repository.
>
> Dan, Cole: what would it take to run this on the fedora-390 build
> machine?

 after a brief look the script needs to be made multi-arch-aware (it
 hard-codes x86_64 in some places), when it calls mock, and then it
 needs some HW (we have ppc64le and s390x even now, aarch64 might
 take a while), overall it looks doable to me. Cole, what do you
 think?

>>>
>>> I'm open to the idea in theory but in practice right now the script
>>> uses mock locally so it's basically tied to the one build machine I
>>> use which is x86. I have arm32 and aarch64 hardware locally but TBH I
>>> have very little interest in running a build farm and dealing with
>>> all the issues of connecting to remote machines, pulling down build
>>> output, etc. In fact I've been meaning to move virt-preview to copr
>>> for a long while which is going to tie it even deeper to x86, this
>>> would make virt-preview easier to enable and let me scrap much of my
>>> custom code for building/uploading repo contents.
>>
>> copr would give us ppc64le and probably aarch64 too in addition to x86,
>> but can't help with s390. We already have build infra internally
>> covering all arches driven by Jenkins, with plans to move the workloads
>> to CentOS infra. I'll look whether or how it could be used for
>> multi-arch virt-preview repos. 
>>
>>> We could re-implement it using koji scratch builds which have multiple
>>> arch support nowadays but I did that in the past for x86 and I recall
>>> feeling it was quite brittle, though I don't remember the details,
>>> maybe it was just my implementation.
>>
>> I suspect the problem with koji scratch builds in this case is that
>> they can't be used in buildroots, which the virt-preview stack requires.
>>
> 
> Good point, but generally virt-preview packages are very loosely coupled
> and don't have strong version dependencies on one another. Occasionally
> a small dependency needs to be updated like libiscsi or libcacard but in
> fact it's been a long time since that's been required.
> 
> - Cole
> 
Hi Cole, for the time being I've patched vdsm to require libvirt 3.7.0-4
(which contains the hotplug patch required by vdsm). Unfortunately, this
release is still only in updates-testing, which lead to a build failure
on ovirt Jenkins.
Do you have an idea by when 3.7.0-4 will be propagated to fedora updates?
Thanks!

-- 
Regards,
 Viktor Mihajlovski

___
Devel mailing list
Devel@ovirt.org

Re: [ovirt-devel] ERROR Internal error: type object 'Stages' has no attribute 'ANSWER_FILE_GENERATED'

[Sandro Bonazzola]

2018-03-01 14:23 GMT+01:00 Eitan Raviv :

> sorry, did not mention i am on rhel 7.3
>

I would suggest to update to rhel 7.4 then as well.



>
> On Thu, Mar 1, 2018 at 2:53 PM, Yedidyah Bar David 
> wrote:
>
>> On Thu, Mar 1, 2018 at 2:25 PM, Eitan Raviv  wrote:
>> > Hi,
>> >
>> > I am getting the above error on the latest master tip when running
>> engine
>> > set-up.
>> >
>> > Anybody can advise?
>>
>> Already discussed here, search for '[ACTION REQUIRED] upgrade to
>> Fedora 27 for otopi on master'.
>>
>> Best regards,
>>
>> >
>> > Thanks
>> >
>> > --
>> > Eitan Raviv
>> > IRC: erav (#ovirt #vdsm #devel #rhev-dev)
>>
>>
>>
>> --
>> Didi
>>
>
>
>
> --
> Eitan Raviv
> IRC: erav (#ovirt #vdsm #devel #rhev-dev)
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ERROR Internal error: type object 'Stages' has no attribute 'ANSWER_FILE_GENERATED'

[Alexander Wels]

On Thursday, March 1, 2018 7:25:16 AM EST Eitan Raviv wrote:
> Hi,
> 
> I am getting the above error on the latest master tip when running engine
> set-up.
> 
> Anybody can advise?
> 
> Thanks

You need to update otopi, if you are running Fedora and its not 27 you need to 
update. 



___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Inventory Analyzer

[Jason Bryant]

Hi Dan,


I was using the Web UI and I uploaded the entire logcollector un-edited 
so nothing was forgotten. As for the version of the analyzer whatever is 
public facing. As for postgres95 I am not sure that is correct as other 
logcollectors uploaded before and after worked no problem from the same 
browser/session.


Thank you,


Jason


On 03/01/2018 05:55 AM, Dan Kenigsberg wrote:

On Mon, Feb 12, 2018 at 5:50 PM, Jason Bryant  wrote:

Hello,

I have attempted a few times to upload a log-collector which has a confirmed
DB in it but I continually get the following error:


An internal error occurred:

('analyzer failed, rc=%s, err=%r', 255, 'Unable to detect the database dump
from sosreport, aborting..\n')

See logs for full stacktrace.

Have you forgotten to attach them?
Which version is the analyzer? Which version was used to collect the
logs? We had a pug due to postgres95 using different filename for
pgdump, it might be what you're seeing.


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ERROR Internal error: type object 'Stages' has no attribute 'ANSWER_FILE_GENERATED'

[Yedidyah Bar David]

On Thu, Mar 1, 2018 at 3:23 PM, Eitan Raviv  wrote:
> sorry, did not mention i am on rhel 7.3

Fine - so as mentioned there, 'yum update otopi' please...

Good luck,

>
> On Thu, Mar 1, 2018 at 2:53 PM, Yedidyah Bar David  wrote:
>>
>> On Thu, Mar 1, 2018 at 2:25 PM, Eitan Raviv  wrote:
>> > Hi,
>> >
>> > I am getting the above error on the latest master tip when running
>> > engine
>> > set-up.
>> >
>> > Anybody can advise?
>>
>> Already discussed here, search for '[ACTION REQUIRED] upgrade to
>> Fedora 27 for otopi on master'.
>>
>> Best regards,
>>
>> >
>> > Thanks
>> >
>> > --
>> > Eitan Raviv
>> > IRC: erav (#ovirt #vdsm #devel #rhev-dev)
>>
>>
>>
>> --
>> Didi
>
>
>
>
> --
> Eitan Raviv
> IRC: erav (#ovirt #vdsm #devel #rhev-dev)



-- 
Didi
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ERROR Internal error: type object 'Stages' has no attribute 'ANSWER_FILE_GENERATED'

[Eitan Raviv]

sorry, did not mention i am on rhel 7.3

On Thu, Mar 1, 2018 at 2:53 PM, Yedidyah Bar David  wrote:

> On Thu, Mar 1, 2018 at 2:25 PM, Eitan Raviv  wrote:
> > Hi,
> >
> > I am getting the above error on the latest master tip when running engine
> > set-up.
> >
> > Anybody can advise?
>
> Already discussed here, search for '[ACTION REQUIRED] upgrade to
> Fedora 27 for otopi on master'.
>
> Best regards,
>
> >
> > Thanks
> >
> > --
> > Eitan Raviv
> > IRC: erav (#ovirt #vdsm #devel #rhev-dev)
>
>
>
> --
> Didi
>



-- 
Eitan Raviv
IRC: erav (#ovirt #vdsm #devel #rhev-dev)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ERROR Internal error: type object 'Stages' has no attribute 'ANSWER_FILE_GENERATED'

[Yedidyah Bar David]

On Thu, Mar 1, 2018 at 2:25 PM, Eitan Raviv  wrote:
> Hi,
>
> I am getting the above error on the latest master tip when running engine
> set-up.
>
> Anybody can advise?

Already discussed here, search for '[ACTION REQUIRED] upgrade to
Fedora 27 for otopi on master'.

Best regards,

>
> Thanks
>
> --
> Eitan Raviv
> IRC: erav (#ovirt #vdsm #devel #rhev-dev)



-- 
Didi
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] ERROR Internal error: type object 'Stages' has no attribute 'ANSWER_FILE_GENERATED'

[Eitan Raviv]

Hi,

I am getting the above error on the latest master tip when running engine
set-up.

Anybody can advise?

Thanks

-- 
Eitan Raviv
IRC: erav (#ovirt #vdsm #devel #rhev-dev)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Inventory Analyzer

[Dan Kenigsberg]

On Mon, Feb 12, 2018 at 5:50 PM, Jason Bryant  wrote:
> Hello,
>
> I have attempted a few times to upload a log-collector which has a confirmed
> DB in it but I continually get the following error:
>
>
> An internal error occurred:
>
> ('analyzer failed, rc=%s, err=%r', 255, 'Unable to detect the database dump
> from sosreport, aborting..\n')
>
> See logs for full stacktrace.

Have you forgotten to attach them?
Which version is the analyzer? Which version was used to collect the
logs? We had a pug due to postgres95 using different filename for
pgdump, it might be what you're seeing.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] FC27 updates broken for ovirt-4.2

[Cole Robinson]

On 02/28/2018 03:39 AM, Dan Horák wrote:
> On Tue, 27 Feb 2018 16:26:28 -0500
> Cole Robinson  wrote:
> 
>> On 02/27/2018 08:03 AM, Dan Horák wrote:
>>> On Tue, 27 Feb 2018 13:54:06 +0100
>>> Viktor Mihajlovski  wrote:
>>>
 On 27.02.2018 13:35, Nir Soffer wrote:
> בתאריך יום ג׳, 27 בפבר׳ 2018, 13:25, מאת Dan Horák
>  ‏:
>
>> On Tue, 27 Feb 2018 10:13:15 +0100
>> Viktor Mihajlovski  wrote:
>>
>>> On 27.02.2018 01:26, Nir Soffer wrote:
 בתאריך יום ב׳, 26 בפבר׳ 2018, 22:10, מאת Yaniv Kaul
  ‏:

> On Mon, Feb 26, 2018 at 7:17 PM, Viktor Mihajlovski <
> mihaj...@linux.vnet.ibm.com> wrote:
>
>> I just tried to update the ovirt packages on my FC27 host,
>> but failed due to https://gerrit.ovirt.org/#/c/87628/
>>
>> vdsm now requires libvirt >= 3.10.0-132 but Fedora 27 has
>> only 3.7.0-4 the moment.
>>
>> It's generic Fedora 27, but since I run on s390,
>> cross-posting to s390 list.
>>
>> I guess there's good reason to require libvirt 3.10. Is there
>> any chance that we can get libvirt updated for Fedora 27?
>>
>
> Perhaps use the virt-preview[1] repo for now?
>

 Yes, we require virt-preview for Fedora. This is why that patch
 did not fail in the CI.
>>> Makes sense, unfortunately virt-preview doesn't contains s390
>>> binaries at this point in time. Would be great if at least
>>> libvirt and qemu could be built for s390.
>>
>> looks like it's even x86_64 only, /me wonders what it would
>> require to offer other arches (aarch64, ppc64le, s390x) as well
>>
>
> If we need to support platform not supported in virt-preview, we
> need to chage the requirement so it is used only on x86_64.
>
> Victor, would you like to send a patch?
 I believe there was a good reason to bump the libvirt requirement
 in the vdsm package (some bugfix). Ideally, virt-preview should be
 build for s390 as well.
 If I'm not mistaking, the script
 https://github.com/crobinso/build-fedora-virt-preview is used to
 build the RPMs and populate the repository.

 Dan, Cole: what would it take to run this on the fedora-390 build
 machine?
>>>
>>> after a brief look the script needs to be made multi-arch-aware (it
>>> hard-codes x86_64 in some places), when it calls mock, and then it
>>> needs some HW (we have ppc64le and s390x even now, aarch64 might
>>> take a while), overall it looks doable to me. Cole, what do you
>>> think?
>>>
>>
>> I'm open to the idea in theory but in practice right now the script
>> uses mock locally so it's basically tied to the one build machine I
>> use which is x86. I have arm32 and aarch64 hardware locally but TBH I
>> have very little interest in running a build farm and dealing with
>> all the issues of connecting to remote machines, pulling down build
>> output, etc. In fact I've been meaning to move virt-preview to copr
>> for a long while which is going to tie it even deeper to x86, this
>> would make virt-preview easier to enable and let me scrap much of my
>> custom code for building/uploading repo contents.
> 
> copr would give us ppc64le and probably aarch64 too in addition to x86,
> but can't help with s390. We already have build infra internally
> covering all arches driven by Jenkins, with plans to move the workloads
> to CentOS infra. I'll look whether or how it could be used for
> multi-arch virt-preview repos. 
> 
>> We could re-implement it using koji scratch builds which have multiple
>> arch support nowadays but I did that in the past for x86 and I recall
>> feeling it was quite brittle, though I don't remember the details,
>> maybe it was just my implementation.
> 
> I suspect the problem with koji scratch builds in this case is that
> they can't be used in buildroots, which the virt-preview stack requires.
> 

Good point, but generally virt-preview packages are very loosely coupled
and don't have strong version dependencies on one another. Occasionally
a small dependency needs to be updated like libiscsi or libcacard but in
fact it's been a long time since that's been required.

- Cole
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] FC27 updates broken for ovirt-4.2

[Cole Robinson]

On 02/27/2018 08:03 AM, Dan Horák wrote:
> On Tue, 27 Feb 2018 13:54:06 +0100
> Viktor Mihajlovski  wrote:
> 
>> On 27.02.2018 13:35, Nir Soffer wrote:
>>> בתאריך יום ג׳, 27 בפבר׳ 2018, 13:25, מאת Dan Horák ‏:
>>>
 On Tue, 27 Feb 2018 10:13:15 +0100
 Viktor Mihajlovski  wrote:

> On 27.02.2018 01:26, Nir Soffer wrote:
>> בתאריך יום ב׳, 26 בפבר׳ 2018, 22:10, מאת Yaniv Kaul
>>  ‏:
>>
>>> On Mon, Feb 26, 2018 at 7:17 PM, Viktor Mihajlovski <
>>> mihaj...@linux.vnet.ibm.com> wrote:
>>>
 I just tried to update the ovirt packages on my FC27 host, but
 failed due to https://gerrit.ovirt.org/#/c/87628/

 vdsm now requires libvirt >= 3.10.0-132 but Fedora 27 has only
 3.7.0-4 the moment.

 It's generic Fedora 27, but since I run on s390, cross-posting
 to s390 list.

 I guess there's good reason to require libvirt 3.10. Is there
 any chance that we can get libvirt updated for Fedora 27?

>>>
>>> Perhaps use the virt-preview[1] repo for now?
>>>
>>
>> Yes, we require virt-preview for Fedora. This is why that patch
>> did not fail in the CI.
> Makes sense, unfortunately virt-preview doesn't contains s390
> binaries at this point in time. Would be great if at least
> libvirt and qemu could be built for s390.

 looks like it's even x86_64 only, /me wonders what it would
 require to offer other arches (aarch64, ppc64le, s390x) as well

>>>
>>> If we need to support platform not supported in virt-preview, we
>>> need to chage the requirement so it is used only on x86_64.
>>>
>>> Victor, would you like to send a patch?
>> I believe there was a good reason to bump the libvirt requirement in
>> the vdsm package (some bugfix). Ideally, virt-preview should be build
>> for s390 as well.
>> If I'm not mistaking, the script
>> https://github.com/crobinso/build-fedora-virt-preview is used to build
>> the RPMs and populate the repository.
>>
>> Dan, Cole: what would it take to run this on the fedora-390 build
>> machine?
> 
> after a brief look the script needs to be made multi-arch-aware (it
> hard-codes x86_64 in some places), when it calls mock, and then it
> needs some HW (we have ppc64le and s390x even now, aarch64 might take
> a while), overall it looks doable to me. Cole, what do you think?
> 

I'm open to the idea in theory but in practice right now the script uses
mock locally so it's basically tied to the one build machine I use which
is x86. I have arm32 and aarch64 hardware locally but TBH I have very
little interest in running a build farm and dealing with all the issues
of connecting to remote machines, pulling down build output, etc. In
fact I've been meaning to move virt-preview to copr for a long while
which is going to tie it even deeper to x86, this would make
virt-preview easier to enable and let me scrap much of my custom code
for building/uploading repo contents.

We could re-implement it using koji scratch builds which have multiple
arch support nowadays but I did that in the past for x86 and I recall
feeling it was quite brittle, though I don't remember the details, maybe
it was just my implementation.

Thanks,
Cole
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Building the oVirt Engine master branch fails due to isort, python issues

[Steven Rosenberg]

Dear Martin,

I should add I am running RHEL 7.4 (Maipo).

With Best Regards.

Steven Rosenberg.

On Mon, Feb 26, 2018 at 2:24 PM, Martin Perina  wrote:

> Didi/Sandro, any ideas about it? AFAIK on CentOS/RHEL 7 everything works
> as expected ...
>
>
> On Mon, Feb 26, 2018 at 11:58 AM, Steven Rosenberg 
> wrote:
>
>> Dear Martin Perina,
>>
>> We found some issues with the oVirt Engine master branch when updating
>> the version via git pull.
>>
>> We then performed the make command:
>>
>> make clean install-dev PREFIX=~/ovirt_engine_master
>> DEV_BUILD_SCL_POSTGRESQL=1
>>
>> It seems a new dependency was added for isort, so the make fails with the
>> following error:
>>
>> 
>> 
>>
>> packaging/setup/plugins/ovirt-engine-rename/ovirt-engine/database.py:313:21:
>> E126 continuation line over-indented for hanging indent
>> packaging/setup/plugins/ovirt-engine-rename/ovirt-engine/database.py:314:21:
>> E126 continuation line over-indented for hanging indent
>> packaging/setup/plugins/ovirt-engine-common/base/core/duplic
>> ated_constants_check.py:109:17: E124 closing bracket does not match
>> visual indentation
>> + ret=1
>> + which isort
>> + echo 'WARNING: tool '\''isort'\'' is missing'
>> WARNING: tool 'isort' is missing
>> + exit 1
>> make[1]: *** [validations] Error 1
>> make[1]: Leaving directory `/home/srosenbe/Documents/git/ovirt-engine'
>> make: *** [all-dev] Error 2
>>
>> 
>> 
>>
>> To attempt to address this issue, we guessed and installed python2-isort
>> through yum, though the readme states it is optional.
>>
>> Though the process continued, it then failed in the python module:
>>
>> /home/srosenbe/Documents/git/ovirt-engine/packaging/pythonli
>> b/ovirt_engine/service.py
>>
>> That error is here:
>>
>> 
>> ---
>>
>>
>> --- /home/srosenbe/Documents/git/ovirt-engine/packaging/pythonli
>> b/ovirt_engine/service.py:before2018-02-12 12:17:26
>> +++ /home/srosenbe/Documents/git/ovirt-engine/packaging/pythonli
>> b/ovirt_engine/service.py:after 2018-02-26 12:07:11.233915
>> @@ -31,6 +31,7 @@
>>  import time
>>
>>  import daemon
>> +
>>
>>  from dateutil import tz
>>
>> + exit 1
>> make[1]: *** [validations] Error 1
>> make[1]: Leaving directory `/home/srosenbe/Documents/git/ovirt-engine'
>> make: *** [all-dev] Error 2
>>
>> 
>> ---
>>
>> Please advise if you have a quick fix or when this issue will be
>> addressed.
>>
>> Thank you for your time and consideration.
>>
>> With Best Regards.
>>
>> Steven Rosenberg.
>>
>>
>
>
> --
> Martin Perina
> Associate Manager, Software Engineering
> Red Hat Czech s.r.o.
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Building the oVirt Engine master branch fails due to isort, python issues

[Steven Rosenberg]

Dear Martin Perina,

We found some issues with the oVirt Engine master branch when updating the
version via git pull.

We then performed the make command:

make clean install-dev PREFIX=~/ovirt_engine_master
DEV_BUILD_SCL_POSTGRESQL=1

It seems a new dependency was added for isort, so the make fails with the
following error:



packaging/setup/plugins/ovirt-engine-rename/ovirt-engine/database.py:313:21:
E126 continuation line over-indented for hanging indent
packaging/setup/plugins/ovirt-engine-rename/ovirt-engine/database.py:314:21:
E126 continuation line over-indented for hanging indent
packaging/setup/plugins/ovirt-engine-common/base/core/duplicated_constants_check.py:109:17:
E124 closing bracket does not match visual indentation
+ ret=1
+ which isort
+ echo 'WARNING: tool '\''isort'\'' is missing'
WARNING: tool 'isort' is missing
+ exit 1
make[1]: *** [validations] Error 1
make[1]: Leaving directory `/home/srosenbe/Documents/git/ovirt-engine'
make: *** [all-dev] Error 2



To attempt to address this issue, we guessed and installed python2-isort
through yum, though the readme states it is optional.

Though the process continued, it then failed in the python module:

/home/srosenbe/Documents/git/ovirt-engine/packaging/pythonlib/ovirt_engine/service.py

That error is here:

---


---
/home/srosenbe/Documents/git/ovirt-engine/packaging/pythonlib/ovirt_engine/service.py:before
2018-02-12 12:17:26
+++
/home/srosenbe/Documents/git/ovirt-engine/packaging/pythonlib/ovirt_engine/service.py:after
2018-02-26 12:07:11.233915
@@ -31,6 +31,7 @@
 import time

 import daemon
+

 from dateutil import tz

+ exit 1
make[1]: *** [validations] Error 1
make[1]: Leaving directory `/home/srosenbe/Documents/git/ovirt-engine'
make: *** [all-dev] Error 2

---

Please advise if you have a quick fix or when this issue will be addressed.

Thank you for your time and consideration.

With Best Regards.

Steven Rosenberg.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Inventory Analyzer

[Jason Bryant]

Hello,

I have attempted a few times to upload a log-collector which has a 
confirmed DB in it but I continually get the following error:



An internal error occurred:

('analyzer failed, rc=%s, err=%r', 255, 'Unable to detect the database dump 
from sosreport, aborting..\n')

See logs for full stacktrace.


Thank you,

Jason
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel