[ovirt-devel] dynamic ownership changes

[Elad Ben Aharon]

We can test this on iSCSI, NFS and GlusterFS. As for ceph and cinder, will
have to check, since usually, we don't execute our automation on them.

On Wed, Apr 11, 2018 at 4:38 PM, Raz Tamir <ratamir at redhat.com> wrote:

> +Elad
>
> On Wed, Apr 11, 2018 at 4:28 PM, Dan Kenigsberg <danken at redhat.com> wrote:
>
>> On Wed, Apr 11, 2018 at 12:34 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>>
>>> On Wed, Apr 11, 2018 at 12:31 PM Eyal Edri <eedri at redhat.com> wrote:
>>>
>>>> Please make sure to run as much OST suites on this patch as possible
>>>> before merging ( using 'ci please build' )
>>>>
>>>
>>> But note that OST is not a way to verify the patch.
>>>
>>> Such changes require testing with all storage types we support.
>>>
>>> Nir
>>>
>>> On Tue, Apr 10, 2018 at 4:09 PM, Martin Polednik <mpolednik at redhat.com>
>>>> wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> I've created a patch[0] that is finally able to activate libvirt's
>>>>> dynamic_ownership for VDSM while not negatively affecting
>>>>> functionality of our storage code.
>>>>>
>>>>> That of course comes with quite a bit of code removal, mostly in the
>>>>> area of host devices, hwrng and anything that touches devices; bunch
>>>>> of test changes and one XML generation caveat (storage is handled by
>>>>> VDSM, therefore disk relabelling needs to be disabled on the VDSM
>>>>> level).
>>>>>
>>>>> Because of the scope of the patch, I welcome storage/virt/network
>>>>> people to review the code and consider the implication this change has
>>>>> on current/future features.
>>>>>
>>>>> [0] https://gerrit.ovirt.org/#/c/89830/
>>>>>
>>>>
>> In particular:  dynamic_ownership was set to 0 prehistorically (as part
>> of https://bugzilla.redhat.com/show_bug.cgi?id=554961 ) because libvirt,
>> running as root, was not able to play properly with root-squash nfs mounts.
>>
>> Have you attempted this use case?
>>
>> I join to Nir's request to run this with storage QE.
>>
>
>
>
> --
>
>
> Raz Tamir
> Manager, RHV QE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180411/1ada0db3/attachment.html>