[ovirt-devel] Re: proposing Ales Musil as a frontend maintainer

[Laura Wright]

+1 Having Ales as a dedicated front end maintainer would be great!

On Thu, May 2, 2019 at 3:12 PM Alona Kaplan  wrote:

>
>
> On Thu, May 2, 2019, 21:42 Greg Sheremeta  wrote:
>
>> Hi all,
>>
>> I'd like to propose Ales Musil as a frontend maintainer for network parts
>> of the admin portal UI. Since joining the team 2 years ago, Ales has
>> quickly become very knowledgeable about all of the GWT intricacies of the
>> admin portal. I trust his expertise and judgment.
>>
>
> +1
>
>
>> Best wishes,
>> Greg
>>
>> --
>>
>> Greg Sheremeta
>>
>> Senior Software Engineer
>>
>> Red Hat 
>> 
>> ___
>> 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/ML5UVKYABG744KHEBSMMEB26D3RYOWR7/
>>
> ___
> 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/O5X2DNQ2GCT45MMKGLRBUU5Q7VHEYYIE/
>


-- 

Laura Wright

She/Her

Associate Interaction Designer, UXD Team

Red Hat 

lwri...@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/GPZ55BAUMXNBPBGWDXAJQCMBZ6VZQZXH/

[ovirt-devel] Re: proposing Ales Musil as a frontend maintainer

[Alona Kaplan]

On Thu, May 2, 2019, 21:42 Greg Sheremeta  wrote:

> Hi all,
>
> I'd like to propose Ales Musil as a frontend maintainer for network parts
> of the admin portal UI. Since joining the team 2 years ago, Ales has
> quickly become very knowledgeable about all of the GWT intricacies of the
> admin portal. I trust his expertise and judgment.
>

+1


> Best wishes,
> Greg
>
> --
>
> Greg Sheremeta
>
> Senior Software Engineer
>
> Red Hat 
> 
> ___
> 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/ML5UVKYABG744KHEBSMMEB26D3RYOWR7/
>
___
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/O5X2DNQ2GCT45MMKGLRBUU5Q7VHEYYIE/

[ovirt-devel] proposing Ales Musil as a frontend maintainer

[Greg Sheremeta]

Hi all,

I'd like to propose Ales Musil as a frontend maintainer for network parts
of the admin portal UI. Since joining the team 2 years ago, Ales has
quickly become very knowledgeable about all of the GWT intricacies of the
admin portal. I trust his expertise and judgment.

Best wishes,
Greg

-- 

Greg Sheremeta

Senior Software Engineer

Red Hat 

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

[ovirt-devel] Jenkins is very slow now - can someone restart it?

[Nir Soffer]

$ time curl -s https://jenkins.ovirt.org/job/ovirt-system-tests_manual/
>/dev/null

real 0m27.380s
user 0m0.038s
sys 0m0.028s

For reference:

$ time curl -s https://travis-ci.org/oVirt/vdsm/builds >/dev/null

real 0m0.614s
user 0m0.027s
sys 0m0.015s

Can someone restart jenkins?
___
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/FEEE5AHK6B6UYGPRXWDFM4EPDQDA2GDE/

[ovirt-devel] Re: OST broken - looks like https://gerrit.ovirt.org/c/99717 is the reason

[Nir Soffer]

On Thu, May 2, 2019 at 7:29 PM Dan Kenigsberg  wrote:

>
>
> On Thu, 2 May 2019, 18:53 Nir Soffer,  wrote:
>
>> Investigating unrelated OST failue with:
>> https://gerrit.ovirt.org/c/99293
>>
>> I found that This patch fail in OST:
>> https://gerrit.ovirt.org/c/99717
>>
>> Failed build:
>> https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4630/
>>
>> 2019-05-02 15:46:07,258::ssh.py::ssh::96::lago.ssh::DEBUG::Command 650bdf66 
>> on lago-basic-suite-master-host-0  errors:
>>  + yum -y install ovirt-host
>> Error: Package: vdsm-common-4.40.0-202.git9757d7c.el7.noarch (alocalsync)
>>Requires: python2-enum34
>>
>>
>> Dan, can you take a look at this?
>>
>
> Wat?! I don't understand how it passed vdsm CI.
>

Maybe we are not using the same repos?
(e.g. testing in CI, stable in OST)

It is sad that passing our install check is not accurate enough, and we need
to fix it, but lets first revert the patch to unblock other work.


>
> worst case I'll revert.
>
>
>> 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/RZUYMEAB4HOE7RLZG4JMEWYARSRORDSK/

[ovirt-devel] Re: OST broken - looks like https://gerrit.ovirt.org/c/99717 is the reason

[Dafna Ron]

if you mean CQ then it did not pass CI - I sent you a mail to look at your
patch as it was failing CQ

On Thu, May 2, 2019 at 7:29 PM Dan Kenigsberg  wrote:

>
>
> On Thu, 2 May 2019, 18:53 Nir Soffer,  wrote:
>
>> Investigating unrelated OST failue with:
>> https://gerrit.ovirt.org/c/99293
>>
>> I found that This patch fail in OST:
>> https://gerrit.ovirt.org/c/99717
>>
>> Failed build:
>> https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4630/
>>
>> 2019-05-02 15:46:07,258::ssh.py::ssh::96::lago.ssh::DEBUG::Command 650bdf66 
>> on lago-basic-suite-master-host-0  errors:
>>  + yum -y install ovirt-host
>> Error: Package: vdsm-common-4.40.0-202.git9757d7c.el7.noarch (alocalsync)
>>Requires: python2-enum34
>>
>>
>> Dan, can you take a look at this?
>>
>
> Wat?! I don't understand how it passed vdsm CI.
>
> worst case I'll revert.
>
>
>> 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/F6IUW6SFQE3A2VDGSFFKTUXC5AYN4XSL/

[ovirt-devel] Re: Thin provisioning??

[Nir Soffer]

On Thu, May 2, 2019 at 7:31 PM Hetz Ben Hamo  wrote:

> OK, which component on bugzilla?
>

It is not clear yet, so start with engine.


>
>
> On Thu, May 2, 2019 at 7:29 PM Nir Soffer  wrote:
>
>> On Thu, May 2, 2019 at 7:18 PM Hetz Ben Hamo  wrote:
>>
>>>
>>> On Thu, May 2, 2019 at 7:15 PM Nir Soffer  wrote:
>>>
 On Thu, May 2, 2019 at 3:59 PM Hetz Ben Hamo  wrote:

> Hi,
>
> I've migrated few Linux VM's from virt-manager to oVirt. Other than
> the famous bug that it insist to have an ISO domain
>

 What is this famous bug?

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


> - it worked well.
>
> My problem is simple: on virt-manager, I created the virtual disks as
> thin provisioning. ls -l shows the full size of the QCOW2 file and du -hs
> shows the actual size. So far, so good.
>

 So the source image was qcow2 image?

>>>
>>> Yes, created with virt-manager.
>>>
>>>

 After migrating those VM's to oVirt, the disks appear both in the web
> UI and in the meta file as "Thin Provisioning" and "sparse" - however,
> digging into the directory which holds the virtual disk and  running du 
> -hs
> - shows it's a full size disk.
>
> Why is this happening?
>

 How did you import the disks?

>>>
>>> Through oVirt - by adding a KVM provider according to ovirt docs.
>>>
>>> In the node it seems to use the kvm2ovirt, ssh and nc to do all the hard
>>> work.
>>>
>>
>> This sounds like kvm2ovirt bug, please file a bug with all the details.
>>
>> Please include the info from engine about the disk format, virtual size,
>> actual size, and
>> output of these commands:
>>
>> qemu-img info /path/to/volume
>> ls -lhs /path/to/volume
>>
>> And engine and vdsm logs showing the import process.
>>
>> Nir
>>
>>
>>
>>>
>>>

 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/634A4VQTXFQCUAYVUOCHZY3QG6IQDRNV/

[ovirt-devel] Re: Thin provisioning??

[Hetz Ben Hamo]

OK, which component on bugzilla?


On Thu, May 2, 2019 at 7:29 PM Nir Soffer  wrote:

> On Thu, May 2, 2019 at 7:18 PM Hetz Ben Hamo  wrote:
>
>>
>> On Thu, May 2, 2019 at 7:15 PM Nir Soffer  wrote:
>>
>>> On Thu, May 2, 2019 at 3:59 PM Hetz Ben Hamo  wrote:
>>>
 Hi,

 I've migrated few Linux VM's from virt-manager to oVirt. Other than the
 famous bug that it insist to have an ISO domain

>>>
>>> What is this famous bug?
>>>
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1632068
>>
>>
>>>
>>>
 - it worked well.

 My problem is simple: on virt-manager, I created the virtual disks as
 thin provisioning. ls -l shows the full size of the QCOW2 file and du -hs
 shows the actual size. So far, so good.

>>>
>>> So the source image was qcow2 image?
>>>
>>
>> Yes, created with virt-manager.
>>
>>
>>>
>>> After migrating those VM's to oVirt, the disks appear both in the web UI
 and in the meta file as "Thin Provisioning" and "sparse" - however, digging
 into the directory which holds the virtual disk and  running du -hs - shows
 it's a full size disk.

 Why is this happening?

>>>
>>> How did you import the disks?
>>>
>>
>> Through oVirt - by adding a KVM provider according to ovirt docs.
>>
>> In the node it seems to use the kvm2ovirt, ssh and nc to do all the hard
>> work.
>>
>
> This sounds like kvm2ovirt bug, please file a bug with all the details.
>
> Please include the info from engine about the disk format, virtual size,
> actual size, and
> output of these commands:
>
> qemu-img info /path/to/volume
> ls -lhs /path/to/volume
>
> And engine and vdsm logs showing the import process.
>
> Nir
>
>
>
>>
>>
>>>
>>> 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/AZRJI4SL4U32DBYTLXFF5CDPCWPBARBC/

[ovirt-devel] Re: Thin provisioning??

[Nir Soffer]

On Thu, May 2, 2019 at 7:18 PM Hetz Ben Hamo  wrote:

>
> On Thu, May 2, 2019 at 7:15 PM Nir Soffer  wrote:
>
>> On Thu, May 2, 2019 at 3:59 PM Hetz Ben Hamo  wrote:
>>
>>> Hi,
>>>
>>> I've migrated few Linux VM's from virt-manager to oVirt. Other than the
>>> famous bug that it insist to have an ISO domain
>>>
>>
>> What is this famous bug?
>>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1632068
>
>
>>
>>
>>> - it worked well.
>>>
>>> My problem is simple: on virt-manager, I created the virtual disks as
>>> thin provisioning. ls -l shows the full size of the QCOW2 file and du -hs
>>> shows the actual size. So far, so good.
>>>
>>
>> So the source image was qcow2 image?
>>
>
> Yes, created with virt-manager.
>
>
>>
>> After migrating those VM's to oVirt, the disks appear both in the web UI
>>> and in the meta file as "Thin Provisioning" and "sparse" - however, digging
>>> into the directory which holds the virtual disk and  running du -hs - shows
>>> it's a full size disk.
>>>
>>> Why is this happening?
>>>
>>
>> How did you import the disks?
>>
>
> Through oVirt - by adding a KVM provider according to ovirt docs.
>
> In the node it seems to use the kvm2ovirt, ssh and nc to do all the hard
> work.
>

This sounds like kvm2ovirt bug, please file a bug with all the details.

Please include the info from engine about the disk format, virtual size,
actual size, and
output of these commands:

qemu-img info /path/to/volume
ls -lhs /path/to/volume

And engine and vdsm logs showing the import process.

Nir



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

[ovirt-devel] Re: OST broken - looks like https://gerrit.ovirt.org/c/99717 is the reason

[Dan Kenigsberg]

On Thu, 2 May 2019, 18:53 Nir Soffer,  wrote:

> Investigating unrelated OST failue with:
> https://gerrit.ovirt.org/c/99293
>
> I found that This patch fail in OST:
> https://gerrit.ovirt.org/c/99717
>
> Failed build:
> https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4630/
>
> 2019-05-02 15:46:07,258::ssh.py::ssh::96::lago.ssh::DEBUG::Command 650bdf66 
> on lago-basic-suite-master-host-0  errors:
>  + yum -y install ovirt-host
> Error: Package: vdsm-common-4.40.0-202.git9757d7c.el7.noarch (alocalsync)
>Requires: python2-enum34
>
>
> Dan, can you take a look at this?
>

Wat?! I don't understand how it passed vdsm CI.

worst case I'll revert.


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

[ovirt-devel] Re: Thin provisioning??

[Hetz Ben Hamo]

On Thu, May 2, 2019 at 7:15 PM Nir Soffer  wrote:

> On Thu, May 2, 2019 at 3:59 PM Hetz Ben Hamo  wrote:
>
>> Hi,
>>
>> I've migrated few Linux VM's from virt-manager to oVirt. Other than the
>> famous bug that it insist to have an ISO domain
>>
>
> What is this famous bug?
>

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


>
>
>> - it worked well.
>>
>> My problem is simple: on virt-manager, I created the virtual disks as
>> thin provisioning. ls -l shows the full size of the QCOW2 file and du -hs
>> shows the actual size. So far, so good.
>>
>
> So the source image was qcow2 image?
>

Yes, created with virt-manager.


>
> After migrating those VM's to oVirt, the disks appear both in the web UI
>> and in the meta file as "Thin Provisioning" and "sparse" - however, digging
>> into the directory which holds the virtual disk and  running du -hs - shows
>> it's a full size disk.
>>
>> Why is this happening?
>>
>
> How did you import the disks?
>

Through oVirt - by adding a KVM provider according to ovirt docs.

In the node it seems to use the kvm2ovirt, ssh and nc to do all the hard
work.


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

[ovirt-devel] Re: Thin provisioning??

[Nir Soffer]

On Thu, May 2, 2019 at 3:59 PM Hetz Ben Hamo  wrote:

> Hi,
>
> I've migrated few Linux VM's from virt-manager to oVirt. Other than the
> famous bug that it insist to have an ISO domain
>

What is this famous bug?


> - it worked well.
>
> My problem is simple: on virt-manager, I created the virtual disks as thin
> provisioning. ls -l shows the full size of the QCOW2 file and du -hs shows
> the actual size. So far, so good.
>

So the source image was qcow2 image?

After migrating those VM's to oVirt, the disks appear both in the web UI
> and in the meta file as "Thin Provisioning" and "sparse" - however, digging
> into the directory which holds the virtual disk and  running du -hs - shows
> it's a full size disk.
>
> Why is this happening?
>

How did you import the disks?

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

[ovirt-devel] OST broken - looks like https://gerrit.ovirt.org/c/99717 is the reason

[Nir Soffer]

Investigating unrelated OST failue with:
https://gerrit.ovirt.org/c/99293

I found that This patch fail in OST:
https://gerrit.ovirt.org/c/99717

Failed build:
https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4630/

2019-05-02 15:46:07,258::ssh.py::ssh::96::lago.ssh::DEBUG::Command
650bdf66 on lago-basic-suite-master-host-0  errors:
 + yum -y install ovirt-host
Error: Package: vdsm-common-4.40.0-202.git9757d7c.el7.noarch (alocalsync)
   Requires: python2-enum34


Dan, can you take a look at this?

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

[ovirt-devel] Thin provisioning??

[Hetz Ben Hamo]

Hi,

I've migrated few Linux VM's from virt-manager to oVirt. Other than the
famous bug that it insist to have an ISO domain - it worked well.

My problem is simple: on virt-manager, I created the virtual disks as thin
provisioning. ls -l shows the full size of the QCOW2 file and du -hs shows
the actual size. So far, so good.

After migrating those VM's to oVirt, the disks appear both in the web UI
and in the meta file as "Thin Provisioning" and "sparse" - however, digging
into the directory which holds the virtual disk and  running du -hs - shows
it's a full size disk.

Why is this happening?

(the storage on the oVirt is NFS)
___
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/5HFPOJME3EPWS2ZK4FX4TLJDXSE7B7U4/

[ovirt-devel] Re: Taking over safelease maintainership

[Dan Kenigsberg]

On Thu, May 2, 2019 at 2:33 PM Sandro Bonazzola  wrote:
>
> Not having former maintainers around and no volunteers to take over 
> maintainership for safelease, I'm taking over its maintainership ad interim.

Thank you, Sandro.
___
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/KBCG7MKHSTHDN2G66OT2VP7ZSP7BCNI4/

[ovirt-devel] Taking over safelease maintainership

[Sandro Bonazzola]

Not having former maintainers around and no volunteers to take over
maintainership for safelease, I'm taking over its maintainership ad interim.

-- 

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

[ovirt-devel] Re: ovirt-system-tests_compat-4.2-suite-master failing for 3 weeks?

[Shani Leviim]

It seems that the storage domain's format wasn't properly set by the
cluster's level (although the cluster level is 4.1 or 4.2, the storage
format was set as v5).
Galit and I are working on it.


*Regards,*

*Shani Leviim*


On Wed, May 1, 2019 at 5:34 PM Tal Nisan  wrote:

> Shani, please have a look
>
> On Wed, May 1, 2019 at 2:34 PM Galit Rosenthal 
> wrote:
>
>> Hi,
>>
>> There is a different issue now (jenkins job [1]):
>>
>> Fault reason is "Operation Failed". Fault detail is "[Cannot attach Storage. 
>> Storage Domain format V5 is illegal.]". HTTP response code is 409.
>>
>>
>> 
>> Can someone take a look?
>>
>> *Error from engine.log:*
>>
>> 2019-05-01 02:00:54,015-04 DEBUG [org.ovirt.engine.core.bll.Backend] 
>> (default task-3) [] Executing command AttachStorageDomainToPool for user 
>> admin@internal-authz.
>> 2019-05-01 02:00:54,032-04 DEBUG 
>> [org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] Checking whether 
>> user 'caa94e16-6bd5-11e9-b8ca-5452c0a8ca02' or one of the groups he is 
>> member of, have the following permissions:  ID: 
>> bb8f0934-0325-474d-9f62-f2983972a16b Type: StorageAction group 
>> MANIPULATE_STORAGE_DOMAIN with role type ADMIN,  ID: 
>> b2c7ddfb-b9ba-4218-b3f1-4b952031de8f Type: StoragePoolAction group 
>> MANIPULATE_STORAGE_DOMAIN with role type ADMIN
>> 2019-05-01 02:00:54,032-04 DEBUG 
>> [org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] Found permission 
>> 'caa959ec-6bd5-11e9-b8cb-5452c0a8ca02' for user when running 
>> 'AttachStorageDomainToPool', on 'Storage' with id 
>> 'bb8f0934-0325-474d-9f62-f2983972a16b'
>> 2019-05-01 02:00:54,033-04 DEBUG 
>> [org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] Found permission 
>> 'caa959ec-6bd5-11e9-b8cb-5452c0a8ca02' for user when running 
>> 'AttachStorageDomainToPool', on 'Data Center' with id 
>> 'b2c7ddfb-b9ba-4218-b3f1-4b952031de8f'
>> 2019-05-01 02:00:54,033-04 DEBUG 
>> [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (default task-3) 
>> [13e92697-ec26-478b-a29e-c652b6006e63] Before acquiring lock 
>> 'EngineLock:{exclusiveLocks='[bb8f0934-0325-474d-9f62-f2983972a16b=STORAGE]',
>>  sharedLocks=''}'
>> 2019-05-01 02:00:54,033-04 DEBUG 
>> [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (default task-3) 
>> [13e92697-ec26-478b-a29e-c652b6006e63] Success acquiring lock 
>> 'EngineLock:{exclusiveLocks='[bb8f0934-0325-474d-9f62-f2983972a16b=STORAGE]',
>>  sharedLocks=''}'
>> 2019-05-01 02:00:54,033-04 INFO  
>> [org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] Lock Acquired to 
>> object 
>> 'EngineLock:{exclusiveLocks='[bb8f0934-0325-474d-9f62-f2983972a16b=STORAGE]',
>>  sharedLocks=''}'
>> 2019-05-01 02:00:54,039-04 DEBUG 
>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] method: 
>> getAllForStoragePoolAndStatus, params: 
>> [b2c7ddfb-b9ba-4218-b3f1-4b952031de8f, Up], timeElapsed: 6ms
>> 2019-05-01 02:00:54,040-04 WARN  
>> [org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] Validation of action 
>> 'AttachStorageDomainToPool' failed for user admin@internal-authz. Reasons: 
>> VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__ATTACH,ACTION_TYPE_FAILED_STORAGE_DOMAIN_FORMAT_ILLEGAL,$storageFormat
>>  V5
>> 2019-05-01 02:00:54,041-04 DEBUG 
>> [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (default task-3) 
>> [13e92697-ec26-478b-a29e-c652b6006e63] Before releasing a lock 
>> 'EngineLock:{exclusiveLocks='[bb8f0934-0325-474d-9f62-f2983972a16b=STORAGE]',
>>  sharedLocks=''}'
>> 2019-05-01 02:00:54,041-04 DEBUG 
>> [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (default task-3) 
>> [13e92697-ec26-478b-a29e-c652b6006e63] The exclusive lock for key 
>> 'bb8f0934-0325-474d-9f62-f2983972a16bSTORAGE' is released and lock is 
>> removed from map
>> 2019-05-01 02:00:54,041-04 INFO  
>> [org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] Lock freed to object 
>> 'EngineLock:{exclusiveLocks='[bb8f0934-0325-474d-9f62-f2983972a16b=STORAGE]',
>>  sharedLocks=''}'
>> 2019-05-01 02:00:54,045-04 DEBUG 
>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] 
>> (default task-3) [13e92697-ec26-478b-a29e-c652b6006e63] method: runAction, 
>> params: [AttachStorageDomainToPool, 
>> AttachStorageDomainToPoolParameters:{commandId='07b837fe-6d86-44f6-81b6-9ddcc4f0cc49',
>>  user='null', commandType='Unknown'}], timeElapsed: 30ms
>> 2019-05-01 02:00:54,049-04 ERROR 
>> [org.ovirt.engine.api.restapi.resource.Abs