[ovirt-devel] Re: [VDSM] Fedora 28 support - updates

2018-11-29 Thread Nir Soffer 
On Wed, Nov 28, 2018 at 5:04 PM Nir Soffer  wrote:

> If you want to add host running Fedora 28, you need to do few manual steps:
>
> 1. Add hosts fail to configure the firewall
>
> Do not check the "Configure filewall" checkbox
>
> Adding host will fail because engine cannot communicate with vdsm.
>
> Fix - disable the firewall on the host.
> $ iptables -F
>
> There is probably a better way, but I did not find it yet :-)
>
> Sandro, do we have an update about this?
>
> 2. Engine fail in Host.getCapabilties
>
> Libvirt changed the location and format of this file. This will cause
> Host.getCapabilties
> to fai, and the host will become "Unassigned"
>
> This is a new issue revealed by updating our virt-preview repo this week.
>
> Fix - install old cpu_map.xml
> $ wget
> https://raw.githubusercontent.com/libvirt/libvirt/18cab54c3a0bc72390f29300684396690a7ecf51/src/cpu/cpu_map.xml
> -O /usr/share/libvirt/cpu_map.xml
>
> Engine should retry and succeed after that.
>
> 3. Sanlock fail to write to its pid file, connecting to storage fail
>
> Fix - set selinux to permissive mode
> $ setenforce 0
>
> To make this persistent edit /etc/selinux/config
> SELINUX=permissive
>
> We have a bug for this.
>

https://bugzilla.redhat.com/1593853

I sent a patch to sanlock-devel:
https://lists.fedorahosted.org/archives/list/sanlock-de...@lists.fedorahosted.org/thread/ZTG4E264IMHVFSVDKDPA6HSGBUFBQ2JI/

If someone want to try the fix, we have scratch build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=31184286

Daniel, Vojta, please install this build and enable selinux. We want to
catch selinux issues
in libvirt backup code early.

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

[ovirt-devel] List of Queries related to RHV

2018-11-29 Thread Suchitra Herwadkar 
Hi Nir, Pavan

https://ovirt.org/develop/release-management/features/storage/incremental-backup/

On reading more from the article, we have some questions which we will like to 
discuss in the call


  1.  Irrespective of the underlying storage, we will always restore the data 
as raw. But it’s not very clear to us how the disk format conversion will be 
taken care of internally by RHV.


  1.  Conversion from raw data to qcow format will only work for disk marked to 
be incremental or it is not specific to that only.
  Would rhv stage the data before conversion to qcow2.


  1.  For this feature( incremental backup) to work, disks have to be marked as 
such. User needs to mark those disks as incrementals while creating VM, 
otherwise this will not work.


  1.  If we use incremental backups, then will there not be a backing file. Do 
we have to upload the entire image and then rhv would convert to qcow. What if 
we want to just upload just the incremental part/changes relative to some base 
image.

Thanks
Suchitra
___
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/47MDMD4GAV44UDPZBQR3JNAOIGKHB6VA/

[ovirt-devel] Re: [VDSM] Fedora 28 support - updates

2018-11-29 Thread Nir Soffer 
On Wed, Nov 28, 2018 at 5:53 PM Martin Perina  wrote:

>
>
> On Wed, 28 Nov 2018, 16:29 Yuval Turgeman 
>> Adding Gal, I think he fixed some of those issues (around add host)
>>
>> On Wed, Nov 28, 2018 at 5:05 PM Nir Soffer  wrote:
>>
>>> If you want to add host running Fedora 28, you need to do few manual
>>> steps:
>>>
>>> 1. Add hosts fail to configure the firewall
>>>
>>> Do not check the "Configure filewall" checkbox
>>>
>>> Adding host will fail because engine cannot communicate with vdsm.
>>>
>>> Fix - disable the firewall on the host.
>>> $ iptables -F
>>>
>>> There is probably a better way, but I did not find it yet :-)
>>>
>>> Sandro, do we have an update about this?
>>>
>>
> AFAIK this has been fixed more than 2 weeks ago in
> https://gerrit.ovirt.org/95286 Could you please retry with updated
> engine?
>

Works, tested with engine commit 7ea281ed097b1710abbf30a122f60607f85234ec.

Thanks!


>
>
>>> 2. Engine fail in Host.getCapabilties
>>>
>>> Libvirt changed the location and format of this file. This will cause
>>> Host.getCapabilties
>>> to fai, and the host will become "Unassigned"
>>>
>>> This is a new issue revealed by updating our virt-preview repo this week.
>>>
>>> Fix - install old cpu_map.xml
>>> $ wget
>>> https://raw.githubusercontent.com/libvirt/libvirt/18cab54c3a0bc72390f29300684396690a7ecf51/src/cpu/cpu_map.xml
>>> -O /usr/share/libvirt/cpu_map.xml
>>>
>>> Engine should retry and succeed after that.
>>>
>>> 3. Sanlock fail to write to its pid file, connecting to storage fail
>>>
>>> Fix - set selinux to permissive mode
>>> $ setenforce 0
>>>
>>> To make this persistent edit /etc/selinux/config
>>> SELINUX=permissive
>>>
>>> We have a bug for this.
>>>
>>> After that you should have a working system.
>>>
>>> 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/RTKM4Y2OSPZO4CEWZVRBUALNGMGHIQ4L/
>>>
>> ___
>> 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/FIFOWMUL3XXPTTEDKOIT6VLO3GJ5R33H/
>>
>
___
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/W3XBAHF6MT4NGQYV63OX6GHTYLFJM46H/

[ovirt-devel] Re: otopi defaults again to python3

2018-11-29 Thread Nir Soffer 
On Thu, Nov 29, 2018, 13:25 Yedidyah Bar David  Hi all,
>
> As some of you might recall, some time ago we made otopi default to
> python3, and quickly reverted that, realizing this causes too much
> breakage.
>
> Now things should hopefully be more stable, and I now merged a patch
> to default to python3 again.


> Current status:
>
> engine-setup works with python3 on fedora.
>
> host-deploy works with python3 on fedora, with both engine being on
> el7 and on fedora. Didn't try on el7, might work as well.


I hope that "might work" good enough :-)

hosted-engine --deploy is most likely broken on fedora, but I think it
> was already broken. We are working on that, but it will require some
> more time - notably, having stuff from vdsm on python3


vdsm is not available on python 3, but this should not be a problem
since you should not import anything from vdsm.

You should use only the vdsmclient package to connect to vdsm and
use vdsm public APIs. But even this library is not available yet for
python 3.

(if not fully
> porting vdsm to python3, which I understand will take even more time).


And we need also sanlock, ioprocess, mom, and ovirt-imageio for python 3.


> If you want to use python2, you can do that with:
>
> OTOPI_PYTHON=/bin/python hosted-engine --deploy
>

Why not keep it using python 2 and provide option to use py3?

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

[ovirt-devel] Re: List of Queries related to RHV

2018-11-29 Thread Nir Soffer 
On Thu, Nov 29, 2018 at 4:41 PM Suchitra Herwadkar <
suchitra.herwad...@veritas.com> wrote:

> Hi Nir, Pavan
>
>
>
>
> https://ovirt.org/develop/release-management/features/storage/incremental-backup/
>
>
>
> On reading more from the article, we have some questions which we will
> like to discuss in the call
>
>
>
>1. Irrespective of the underlying storage, we will always restore the
>data as raw. But it’s not very clear to us how the disk format conversion
>will be taken care of internally by RHV.
>
>
It works like this:

1. you create a new disk or add a new snapshot

2. you start a transfer with source_format=raw (not final API yet)

3. RHV knows the both the disk format and the source format, so it can
setup the upload to do automatic conversion:

   - If no conversion is needed, RHV can setup direct upload - imageio
daemon
  will be configured to write direct to the image
(file:///rhev/data-center/...)

  - if conversion is needed, RHV will start qemu-nbd process on the upload
host
and the imageio daemon will be configured with nbd url
(nbd:unix:/run/vdsm/nbd/...)

4. RHV returns upload url

5. you upload using the upload url

6. imageio daemon write the data to the either file (data written as is) or
nbd
   (data converted).


>
>1. Conversion from raw data to qcow format will only work for disk
>marked to be incremental or it is not specific to that only.
>
>   Would rhv stage the data before conversion to qcow2.
>

No, we stream data to/from storage or nbd server.


>
>
>1. For this feature( incremental backup) to work, disks have to be
>marked as such. User needs to mark those disks as incrementals while
>creating VM, otherwise this will not work.
>
> The limit is the image format - if a disk is using raw format, we cannot
do incremantl
backup. We can support creating full backup using the nbd based pipeline,
but
this is not planned for the first version supporting incremental backup.

If the user mark the disk for incremental backup, we will always use qcow2
format,
so we can include the disk in incremental backup.


>1. If we use incremental backups, then will there not be a backing
>file. Do we have to upload the entire image and then rhv would convert to
>qcow. What if we want to just upload just the incremental part/changes
>relative to some base image.
>
> You can do this:

1. add a new snapshot
2. determine which data need to be written to disk
3. upload only this data to the snapshot

The user can keep the snapshot, or merge it into the previous snaphost
to "commit" the backup.

If the user want revert the restore, she can preview the previous snapshot
and commit.

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

[ovirt-devel] Re: Failing OST patches

2018-11-29 Thread Eyal Edri 
Galit/Dafna,
Do we know of any existing add host failures that are being fixed/handled?
Can you help review these errors?

On Thu, Nov 29, 2018 at 2:35 PM Kaustav Majumder 
wrote:

> Recently I have pushed 2 patches for OST[1][2], both are  failing in CI.
> Though unrelated failures I find the errors in "add_hosts" test beacuse the
> host is non operation within the asserted time.I have added the link for
> the jenkins log [3].
>
> [1] https://gerrit.ovirt.org/#/c/95327/
> [2] https://gerrit.ovirt.org/#/c/95347/
> [3] https://pastebin.com/MVpws4Et
>
> Any advice?
> --
>
> KAUSTAV MAJUMDER
>
> ASSOCIATE SOFTWARE ENGINEER
>
> Red Hat India PVT LTD. 
>
> kmajum...@redhat.comM: 08981884037 IM: IRC: kmajumder
> 
> TRIED. TESTED. TRUSTED. 
> @redhatway    @redhatinc
>    @redhatsnaps
> 
> ___
> 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/KHLOVT3GJHFH7WVVSFH32S32OZ6JJZRG/
>


-- 

Eyal edri


MANAGER

RHV/CNV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
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/JTC4XY25DMJFDFOAKCKIL3HFDNWUNDLF/

[ovirt-devel] Failing OST patches

2018-11-29 Thread Kaustav Majumder 
Recently I have pushed 2 patches for OST[1][2], both are  failing in CI.
Though unrelated failures I find the errors in "add_hosts" test beacuse the
host is non operation within the asserted time.I have added the link for
the jenkins log [3].

[1] https://gerrit.ovirt.org/#/c/95327/
[2] https://gerrit.ovirt.org/#/c/95347/
[3] https://pastebin.com/MVpws4Et

Any advice?
-- 

KAUSTAV MAJUMDER

ASSOCIATE SOFTWARE ENGINEER

Red Hat India PVT LTD. 

kmajum...@redhat.comM: 08981884037 IM: IRC: kmajumder

TRIED. TESTED. TRUSTED. 
@redhatway    @redhatinc
   @redhatsnaps

___
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/KHLOVT3GJHFH7WVVSFH32S32OZ6JJZRG/

[ovirt-devel] Need help setting default value to a dropdown variable in webadmin

2018-11-29 Thread Kaustav Majumder 
Hi all,
Have been struggling with gwt code while trying to set a default value to a
list drop down if a condition is satisfied.
The class I am working on is "VmDiskPopupWidget.java" . I need to set
default Allocation Policy 'volumeType' as 'Preallocated'.

The select dropdown is of type 'ListModelListBoxEditor'
Any advice.
-- 

KAUSTAV MAJUMDER

ASSOCIATE SOFTWARE ENGINEER

Red Hat India PVT LTD. 

kmajum...@redhat.comM: 08981884037 IM: IRC: kmajumder

TRIED. TESTED. TRUSTED. 
@redhatway    @redhatinc
   @redhatsnaps

___
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/43WKX2XRAZX7UZBO5WQFMNIVHW6WJZRI/

[ovirt-devel] Re: [VDSM] Fedora 28 support - updates

2018-11-29 Thread Milan Zamazal 
Michal Skrivanek  writes:

>> On 29 Nov 2018, at 06:04, Michal Skrivanek  
>> wrote:
>> 
>> 
>> 
>>> On 28 Nov 2018, at 11:05, Nir Soffer >> > wrote:
>>> 
>>> On Wed, Nov 28, 2018 at 5:53 PM Martin Perina >> > wrote:
>>> 
>>> 
>>> On Wed, 28 Nov 2018, 16:29 Yuval Turgeman >>  wrote:
>>> Adding Gal, I think he fixed some of those issues (around add host)
>>> 
>>> On Wed, Nov 28, 2018 at 5:05 PM Nir Soffer >> > wrote:
>>> If you want to add host running Fedora 28, you need to do few manual steps:
>>> 
>>> 1. Add hosts fail to configure the firewall
>>> 
>>> Do not check the "Configure filewall" checkbox
>>> 
>>> Adding host will fail because engine cannot communicate with vdsm.
>>> 
>>> Fix - disable the firewall on the host.
>>> $ iptables -F
>>> 
>>> There is probably a better way, but I did not find it yet :-)
>>> 
>>> Sandro, do we have an update about this?
>>> 
>>> AFAIK this has been fixed more than 2 weeks ago in
>>> https://gerrit.ovirt.org/95286 
>>> Could you please retry with updated engine?
>>> 
>>> I'll test this, thanks.
>>>  
>>> 
>>> 
>>> 2. Engine fail in Host.getCapabilties 
>>> 
>>> Libvirt changed the location and format of this file. This will cause 
>>> Host.getCapabilties 
>>> to fai, and the host will become "Unassigned"
>>> 
>>> This is a new issue revealed by updating our virt-preview repo this week.
>> 
>> yeah, apparently a change in libvirt 4.7[1]. More changes are about
>> to follow and we will need to change the logic how we get CPUs from
>> libvirt eventually.
>> For now a simple check for both locations should do
>
> Bleh, sorry, no it won’t
> So, Milan, the right way would be to query the capabilities which is
> not a trivial change…but it is the only way how to stop reading
> libvirt internal configs.
> Is that what you’re planning to do?

Not initially, but indeed it looks like the right way.  I'll do it.

>> Thanks,
>> michal
>> 
>> [1]
>> https://libvirt.org/git/?p=libvirt.git;a=commit;h=3ecbac95cd2a02ba5e2f98c625386ec12c8bbdac
>> 
>> 
>>> 
>>> Fix - install old cpu_map.xml
>>> $ wget
>>> https://raw.githubusercontent.com/libvirt/libvirt/18cab54c3a0bc72390f29300684396690a7ecf51/src/cpu/cpu_map.xml
>>> 
>>> -O /usr/share/libvirt/cpu_map.xml
>>> 
>>> Engine should retry and succeed after that.
>>> 
>>> 3. Sanlock fail to write to its pid file, connecting to storage fail
>>> 
>>> Fix - set selinux to permissive mode
>>> $ setenforce 0
>>> 
>>> To make this persistent edit /etc/selinux/config
>>> SELINUX=permissive
>>> 
>>> We have a bug for this.
>>> 
>>> After that you should have a working system.
>>> 
>>> 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/RTKM4Y2OSPZO4CEWZVRBUALNGMGHIQ4L/
>>> 
>>> ___
>>> 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/FIFOWMUL3XXPTTEDKOIT6VLO3GJ5R33H/
>>> 
>>> ___
>>> 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/ETVT56EYWTPDLSFXTEN5OLLKGDC34Y34/
>>>

[ovirt-devel] otopi defaults again to python3

2018-11-29 Thread Yedidyah Bar David 
Hi all,

As some of you might recall, some time ago we made otopi default to
python3, and quickly reverted that, realizing this causes too much
breakage.

Now things should hopefully be more stable, and I now merged a patch
to default to python3 again.

Current status:

engine-setup works with python3 on fedora.

host-deploy works with python3 on fedora, with both engine being on
el7 and on fedora. Didn't try on el7, might work as well.

hosted-engine --deploy is most likely broken on fedora, but I think it
was already broken. We are working on that, but it will require some
more time - notably, having stuff from vdsm on python3 (if not fully
porting vdsm to python3, which I understand will take even more time).
If you want to use python2, you can do that with:

OTOPI_PYTHON=/bin/python hosted-engine --deploy

On el7, if you manually added python3 (which is not available in the
base repos), things will break - use above workaround if needed.

Best regards,
-- 
Didi
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/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/2VSR7LZ36OAIMJZDUJKKRN4OUJR3X2EU/

[ovirt-devel] Re: [VDSM] Fedora 28 support - updates

2018-11-29 Thread Michal Skrivanek 


> On 29 Nov 2018, at 06:04, Michal Skrivanek  
> wrote:
> 
> 
> 
>> On 28 Nov 2018, at 11:05, Nir Soffer > > wrote:
>> 
>> On Wed, Nov 28, 2018 at 5:53 PM Martin Perina > > wrote:
>> 
>> 
>> On Wed, 28 Nov 2018, 16:29 Yuval Turgeman >  wrote:
>> Adding Gal, I think he fixed some of those issues (around add host)
>> 
>> On Wed, Nov 28, 2018 at 5:05 PM Nir Soffer > > wrote:
>> If you want to add host running Fedora 28, you need to do few manual steps:
>> 
>> 1. Add hosts fail to configure the firewall
>> 
>> Do not check the "Configure filewall" checkbox
>> 
>> Adding host will fail because engine cannot communicate with vdsm.
>> 
>> Fix - disable the firewall on the host.
>> $ iptables -F
>> 
>> There is probably a better way, but I did not find it yet :-)
>> 
>> Sandro, do we have an update about this?
>> 
>> AFAIK this has been fixed more than 2 weeks ago in 
>> https://gerrit.ovirt.org/95286  Could you 
>> please retry with updated engine? 
>> 
>> I'll test this, thanks.
>>  
>> 
>> 
>> 2. Engine fail in Host.getCapabilties 
>> 
>> Libvirt changed the location and format of this file. This will cause 
>> Host.getCapabilties 
>> to fai, and the host will become "Unassigned"
>> 
>> This is a new issue revealed by updating our virt-preview repo this week.
> 
> yeah, apparently a change in libvirt 4.7[1]. More changes are about to follow 
> and we will need to change the logic how we get CPUs from libvirt eventually.
> For now a simple check for both locations should do

Bleh, sorry, no it won’t
So, Milan, the right way would be to query the capabilities which is not a 
trivial change…but it is the only way how to stop reading libvirt internal 
configs.
Is that what you’re planning to do?

> 
> Thanks,
> michal
> 
> [1] 
> https://libvirt.org/git/?p=libvirt.git;a=commit;h=3ecbac95cd2a02ba5e2f98c625386ec12c8bbdac
>  
> 
> 
>> 
>> Fix - install old cpu_map.xml
>> $ wget 
>> https://raw.githubusercontent.com/libvirt/libvirt/18cab54c3a0bc72390f29300684396690a7ecf51/src/cpu/cpu_map.xml
>>  
>> 
>>  -O /usr/share/libvirt/cpu_map.xml
>> 
>> Engine should retry and succeed after that.
>> 
>> 3. Sanlock fail to write to its pid file, connecting to storage fail
>> 
>> Fix - set selinux to permissive mode
>> $ setenforce 0
>> 
>> To make this persistent edit /etc/selinux/config
>> SELINUX=permissive
>> 
>> We have a bug for this.
>> 
>> After that you should have a working system.
>> 
>> 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/RTKM4Y2OSPZO4CEWZVRBUALNGMGHIQ4L/
>>  
>> 
>> ___
>> 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/FIFOWMUL3XXPTTEDKOIT6VLO3GJ5R33H/
>>  
>> 
>> ___
>> 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/ETVT56EYWTPDLSFXTEN5OLLKGDC34Y34/
>>  
>> 
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email

[ovirt-devel] Re: [VDSM] Fedora 28 support - updates

2018-11-29 Thread Michal Skrivanek 


> On 28 Nov 2018, at 11:05, Nir Soffer  wrote:
> 
> On Wed, Nov 28, 2018 at 5:53 PM Martin Perina  > wrote:
> 
> 
> On Wed, 28 Nov 2018, 16:29 Yuval Turgeman   wrote:
> Adding Gal, I think he fixed some of those issues (around add host)
> 
> On Wed, Nov 28, 2018 at 5:05 PM Nir Soffer  > wrote:
> If you want to add host running Fedora 28, you need to do few manual steps:
> 
> 1. Add hosts fail to configure the firewall
> 
> Do not check the "Configure filewall" checkbox
> 
> Adding host will fail because engine cannot communicate with vdsm.
> 
> Fix - disable the firewall on the host.
> $ iptables -F
> 
> There is probably a better way, but I did not find it yet :-)
> 
> Sandro, do we have an update about this?
> 
> AFAIK this has been fixed more than 2 weeks ago in 
> https://gerrit.ovirt.org/95286  Could you 
> please retry with updated engine? 
> 
> I'll test this, thanks.
>  
> 
> 
> 2. Engine fail in Host.getCapabilties 
> 
> Libvirt changed the location and format of this file. This will cause 
> Host.getCapabilties 
> to fai, and the host will become "Unassigned"
> 
> This is a new issue revealed by updating our virt-preview repo this week.

yeah, apparently a change in libvirt 4.7[1]. More changes are about to follow 
and we will need to change the logic how we get CPUs from libvirt eventually.
For now a simple check for both locations should do

Thanks,
michal

[1] 
https://libvirt.org/git/?p=libvirt.git;a=commit;h=3ecbac95cd2a02ba5e2f98c625386ec12c8bbdac

> 
> Fix - install old cpu_map.xml
> $ wget 
> https://raw.githubusercontent.com/libvirt/libvirt/18cab54c3a0bc72390f29300684396690a7ecf51/src/cpu/cpu_map.xml
>  
> 
>  -O /usr/share/libvirt/cpu_map.xml
> 
> Engine should retry and succeed after that.
> 
> 3. Sanlock fail to write to its pid file, connecting to storage fail
> 
> Fix - set selinux to permissive mode
> $ setenforce 0
> 
> To make this persistent edit /etc/selinux/config
> SELINUX=permissive
> 
> We have a bug for this.
> 
> After that you should have a working system.
> 
> 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/RTKM4Y2OSPZO4CEWZVRBUALNGMGHIQ4L/
>  
> 
> ___
> 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/FIFOWMUL3XXPTTEDKOIT6VLO3GJ5R33H/
>  
> 
> ___
> 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/ETVT56EYWTPDLSFXTEN5OLLKGDC34Y34/

___
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/MB5NSAYKCGFRZ7PRWLB7KK32TDAFG6HK/

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

2018-11-29 Thread Edward Haas 
On Thu, Nov 29, 2018 at 10:41 AM Edward Haas  wrote:

>
>
> On Wed, Nov 28, 2018 at 8:12 PM Nir Soffer  wrote:
>
>> We have this failure that pops randomly:
>>
>> 1. All tests pass
>>
>> *00:13:13.284* ___ summary 
>> *00:13:13.285*   tests: commands 
>> succeeded*00:13:13.286*   storage-py27: commands succeeded*00:13:13.286*   
>> storage-py36: commands succeeded*00:13:13.286*   lib-py27: commands 
>> succeeded*00:13:13.287*   lib-py36: commands succeeded*00:13:13.288*   
>> network-py27: commands succeeded*00:13:13.290*   network-py36: commands 
>> succeeded*00:13:13.291*   virt-py27: commands succeeded*00:13:13.292*   
>> virt-py36: commands succeeded*00:13:13.293*   congratulations :)
>>
>>
>> 2. But we fail to collect logs at the end
>>
>> *00:14:35.992* 
>> ##*00:14:35.995* ## 
>> Wed Nov 28 17:39:50 UTC 2018 Finished env: 
>> fc28:fedora-28-x86_64*00:14:35.996* ##  took 764 seconds*00:14:35.997* 
>> ##  rc = 1*00:14:35.997* 
>> ##*00:14:36.009* ##! 
>> ERROR v*00:14:36.010* ##! Last 20 
>> log entries: /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* 
>> ##!*00:14:36.012* 
>> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013* tar: 
>> journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we 
>> read it*00:14:36.014* 
>> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015* 
>> lastlog*00:14:36.015* libvirt/*00:14:36.015* libvirt/lxc/*00:14:36.015* 
>> libvirt/libxl/*00:14:36.016* libvirt/qemu/*00:14:36.016* 
>> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017* 
>> libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* 
>> ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* README*00:14:36.018* 
>> samba/*00:14:36.018* samba/old/*00:14:36.018* sssd/*00:14:36.018* 
>> tallylog*00:14:36.018* wtmp*00:14:36.018* Took 678 seconds*00:14:36.018* 
>> ===*00:14:36.019* ##!*00:14:36.019* ##! 
>> ERROR ^^*00:14:36.019* 
>> ##!
>>
>>
>> This looks like an issue with vdsm check-patch.sh:
>>
>> function collect_logs {
>> res=$?
>> [ "$res" -ne 0 ] && echo "*** err: $res"
>> cd /var/log
>> tar -cvzf "$EXPORT_DIR/mock_varlogs.tar.gz" *
>> cd /var/host_log
>> tar -cvzf "$EXPORT_DIR/host_varlogs.tar.gz" *
>> }
>>
>> trap collect_logs EXIT
>>
>> Seems that tar fail to collect log if the log is modified while copied,
>> which makes sense.
>>
>> We can ignore errors in tar, since log collection should not fail the
>> build, but I think
>> a better solution is to avoid collecting any logs since vdsm writes its
>> own logs during
>> tests - all the info must be in vdsm log.
>>
>> Here is the list of collected logs:
>>
>> *00:13:47.280* + tar -cvzf 
>> /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/mock_varlogs.tar.gz
>>  btmp dnf.librepo.log dnf.log dnf.rpm.log faillog glusterfs hawkey.log 
>> journal lastlog libvirt openvswitch README tallylog vdsm_tests.log wtmp 
>> yum.log*00:13:47.285* btmp*00:13:47.285* dnf.librepo.log*00:13:47.299* 
>> dnf.log*00:13:47.309* dnf.rpm.log*00:13:47.310* faillog*00:13:47.311* 
>> glusterfs/*00:13:47.312* hawkey.log*00:13:47.313* journal/*00:13:47.313* 
>> lastlog*00:13:47.315* libvirt/*00:13:47.315* libvirt/qemu/*00:13:47.316* 
>> openvswitch/*00:13:47.317* openvswitch/ovs-vswitchd.log*00:13:47.318* 
>> openvswitch/ovsdb-server.log*00:13:47.319* README*00:13:47.320* 
>> tallylog*00:13:47.321* vdsm_tests.log*00:13:47.342* wtmp*00:13:47.343* 
>> yum.log*00:13:47.349* + cd /var/host_log*00:13:47.350* + tar -cvzf 
>> /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/host_varlogs.tar.gz
>>  anaconda audit boot.log btmp chrony cloud-init.log cloud-init-output.log 
>> cron dnf.librepo.log dnf.log dnf.rpm.log firewalld glusterfs hawkey.log 
>> journal lastlog libvirt ovirt-guest-agent README samba sssd tallylog 
>> wtmp*00:13:47.356* anaconda/*00:13:47.356* anaconda/ifcfg.log*00:13:47.357* 
>> anaconda/ks-script-l5qnynnj.log*00:13:47.358* 
>> anaconda/storage.log*00:13:47.359* anaconda/program.log*00:13:47.395* 
>> anaconda/ks-script-b5_08tmo.log*00:13:47.396* 
>> anaconda/ks-script-6uks8bp3.log*00:13:47.397* 
>> anaconda/hawkey.log*00:13:47.398* anaconda/syslog*00:13:47.406* 
>> anaconda/journal.log*00:13:47.449* anaconda/dnf.librepo.log*00:13:47.458* 
>> anaconda/packaging.log*00:13:47.465* anaconda/dbus.log*00:13:47.466* 
>> anaconda/anaconda.log*00:13:47.467* 
>> anaconda/ks-script-slrcz39_.log*00:13:47.503* audit/*00:13:47.504* 
>> audit/audit.log.3*00:13:47.657* audit/audit.log.2*00:13:47.814* 
>> audit/audit.log.1*00:13:47.981*

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

2018-11-29 Thread Edward Haas 
On Wed, Nov 28, 2018 at 8:12 PM Nir Soffer  wrote:

> We have this failure that pops randomly:
>
> 1. All tests pass
>
> *00:13:13.284* ___ summary 
> *00:13:13.285*   tests: commands 
> succeeded*00:13:13.286*   storage-py27: commands succeeded*00:13:13.286*   
> storage-py36: commands succeeded*00:13:13.286*   lib-py27: commands 
> succeeded*00:13:13.287*   lib-py36: commands succeeded*00:13:13.288*   
> network-py27: commands succeeded*00:13:13.290*   network-py36: commands 
> succeeded*00:13:13.291*   virt-py27: commands succeeded*00:13:13.292*   
> virt-py36: commands succeeded*00:13:13.293*   congratulations :)
>
>
> 2. But we fail to collect logs at the end
>
> *00:14:35.992* 
> ##*00:14:35.995* ## 
> Wed Nov 28 17:39:50 UTC 2018 Finished env: 
> fc28:fedora-28-x86_64*00:14:35.996* ##  took 764 seconds*00:14:35.997* ## 
>  rc = 1*00:14:35.997* 
> ##*00:14:36.009* ##! 
> ERROR v*00:14:36.010* ##! Last 20 log 
> entries: /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* 
> ##!*00:14:36.012* 
> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013* tar: 
> journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we 
> read it*00:14:36.014* 
> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015* 
> lastlog*00:14:36.015* libvirt/*00:14:36.015* libvirt/lxc/*00:14:36.015* 
> libvirt/libxl/*00:14:36.016* libvirt/qemu/*00:14:36.016* 
> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017* 
> libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* 
> ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* README*00:14:36.018* 
> samba/*00:14:36.018* samba/old/*00:14:36.018* sssd/*00:14:36.018* 
> tallylog*00:14:36.018* wtmp*00:14:36.018* Took 678 seconds*00:14:36.018* 
> ===*00:14:36.019* ##!*00:14:36.019* ##! ERROR 
> ^^*00:14:36.019* 
> ##!
>
>
> This looks like an issue with vdsm check-patch.sh:
>
> function collect_logs {
> res=$?
> [ "$res" -ne 0 ] && echo "*** err: $res"
> cd /var/log
> tar -cvzf "$EXPORT_DIR/mock_varlogs.tar.gz" *
> cd /var/host_log
> tar -cvzf "$EXPORT_DIR/host_varlogs.tar.gz" *
> }
>
> trap collect_logs EXIT
>
> Seems that tar fail to collect log if the log is modified while copied,
> which makes sense.
>
> We can ignore errors in tar, since log collection should not fail the
> build, but I think
> a better solution is to avoid collecting any logs since vdsm writes its
> own logs during
> tests - all the info must be in vdsm log.
>
> Here is the list of collected logs:
>
> *00:13:47.280* + tar -cvzf 
> /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/mock_varlogs.tar.gz
>  btmp dnf.librepo.log dnf.log dnf.rpm.log faillog glusterfs hawkey.log 
> journal lastlog libvirt openvswitch README tallylog vdsm_tests.log wtmp 
> yum.log*00:13:47.285* btmp*00:13:47.285* dnf.librepo.log*00:13:47.299* 
> dnf.log*00:13:47.309* dnf.rpm.log*00:13:47.310* faillog*00:13:47.311* 
> glusterfs/*00:13:47.312* hawkey.log*00:13:47.313* journal/*00:13:47.313* 
> lastlog*00:13:47.315* libvirt/*00:13:47.315* libvirt/qemu/*00:13:47.316* 
> openvswitch/*00:13:47.317* openvswitch/ovs-vswitchd.log*00:13:47.318* 
> openvswitch/ovsdb-server.log*00:13:47.319* README*00:13:47.320* 
> tallylog*00:13:47.321* vdsm_tests.log*00:13:47.342* wtmp*00:13:47.343* 
> yum.log*00:13:47.349* + cd /var/host_log*00:13:47.350* + tar -cvzf 
> /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/host_varlogs.tar.gz
>  anaconda audit boot.log btmp chrony cloud-init.log cloud-init-output.log 
> cron dnf.librepo.log dnf.log dnf.rpm.log firewalld glusterfs hawkey.log 
> journal lastlog libvirt ovirt-guest-agent README samba sssd tallylog 
> wtmp*00:13:47.356* anaconda/*00:13:47.356* anaconda/ifcfg.log*00:13:47.357* 
> anaconda/ks-script-l5qnynnj.log*00:13:47.358* 
> anaconda/storage.log*00:13:47.359* anaconda/program.log*00:13:47.395* 
> anaconda/ks-script-b5_08tmo.log*00:13:47.396* 
> anaconda/ks-script-6uks8bp3.log*00:13:47.397* 
> anaconda/hawkey.log*00:13:47.398* anaconda/syslog*00:13:47.406* 
> anaconda/journal.log*00:13:47.449* anaconda/dnf.librepo.log*00:13:47.458* 
> anaconda/packaging.log*00:13:47.465* anaconda/dbus.log*00:13:47.466* 
> anaconda/anaconda.log*00:13:47.467* 
> anaconda/ks-script-slrcz39_.log*00:13:47.503* audit/*00:13:47.504* 
> audit/audit.log.3*00:13:47.657* audit/audit.log.2*00:13:47.814* 
> audit/audit.log.1*00:13:47.981* audit/audit.log*00:13:48.008* 
> audit/audit.log.4*00:13:48.155* boot.log*00:13:48.156* btmp*00:13:48.157* 
> chrony/*00:13:48.159* cloud-init.log*00:13:48.159* 
>