Execution is done, 59/65 cases passed. Latest 4.2.4 execution ended with 100% so failures were caused probably due to the changes done in the patch. Failures are mainly on preview snapshots.
Execution info provided to Martin separately. On Wed, May 30, 2018 at 5:44 PM, Elad Ben Aharon <[email protected]> wrote: > Triggered a sanity automation execution using [1], which covers all the > requested areas, on iSCSI, NFS and Gluster. > I'll update with the results. > > [1] > *https://gerrit.ovirt.org/#/c/90906/ <https://gerrit.ovirt.org/#/c/90906/>* > vdsm-4.20.28-6.gitc23aef6.el7.x86_64 > > > On Tue, May 29, 2018 at 4:26 PM, Martin Polednik <[email protected]> > wrote: > >> On 29/05/18 15:30 +0300, Elad Ben Aharon wrote: >> >>> Hi Martin, >>> >>> Can you please create a cerry pick patch that is based on 4.2? >>> >> >> See https://gerrit.ovirt.org/#/c/90906/. The CI failure isn unrelated >> (storage needs real env). >> >> mpolednik >> >> >> >>> Thanks >>> >>> On Tue, May 29, 2018 at 1:34 PM, Dan Kenigsberg <[email protected]> >>> wrote: >>> >>> On Tue, May 29, 2018 at 1:21 PM, Elad Ben Aharon <[email protected]> >>>> wrote: >>>> > Hi Dan, >>>> > >>>> > In the last execution, the success rate was very low due to a large >>>> number >>>> > of failures on start VM caused, according to Michal, by the >>>> > vdsm-hook-allocate_net that was installed on the host. >>>> > >>>> > This is the latest status here, would you like me to re-execute? >>>> >>>> yes, of course. but you should rebase Polednik's code on top of >>>> *current* ovirt-4.2.3 branch. >>>> >>>> > If so, with >>>> > or W/O vdsm-hook-allocate_net installed? >>>> >>>> There was NO reason to have that installed. Please keep it (and any >>>> other needless code) out of the test environment. >>>> >>>> > >>>> > On Tue, May 29, 2018 at 1:14 PM, Dan Kenigsberg <[email protected]> >>>> wrote: >>>> >> >>>> >> On Mon, May 7, 2018 at 3:53 PM, Michal Skrivanek >>>> >> <[email protected]> wrote: >>>> >> > Hi Elad, >>>> >> > why did you install vdsm-hook-allocate_net? >>>> >> > >>>> >> > adding Dan as I think the hook is not supposed to fail this badly >>>> in >>>> any >>>> >> > case >>>> >> >>>> >> yep, this looks bad and deserves a little bug report. Installing this >>>> >> little hook should not block vm startup. >>>> >> >>>> >> But more importantly - what is the conclusion of this thread? Do we >>>> >> have a green light from QE to take this in? >>>> >> >>>> >> >>>> >> > >>>> >> > Thanks, >>>> >> > michal >>>> >> > >>>> >> > On 5 May 2018, at 19:22, Elad Ben Aharon <[email protected]> >>>> wrote: >>>> >> > >>>> >> > Start VM fails on: >>>> >> > >>>> >> > 2018-05-05 17:53:27,399+0300 INFO (vm/e6ce66ce) [virt.vm] >>>> >> > (vmId='e6ce66ce-852f-48c5-9997-5d2959432a27') drive 'vda' path: >>>> >> > >>>> >> > 'dev=/rhev/data-center/mnt/blockSD/db5a6696-d907-4938- >>>> 9a78-bdd13a843c62/images/6cdabfe5- >>>> >> > d1ca-40af-ae63-9834f235d1c8/7ef97445-30e6-4435-8425-f35a01928211' >>>> -> >>>> >> > >>>> >> > u'*dev=/rhev/data-center/mnt/blockSD/db5a6696-d907-4938- >>>> 9a78-bdd13a843c62/images/6cdabfe5-d1ca-40af-ae63- >>>> 9834f235d1c8/7ef97445-30e6-4435-8425- >>>> >> > f35a01928211' (storagexml:334) >>>> >> > 2018-05-05 17:53:27,888+0300 INFO (jsonrpc/1) [vdsm.api] START >>>> >> > getSpmStatus(spUUID='940fe6f3-b0c6-4d0c-a921-198e7819c1cc', >>>> >> > options=None) >>>> >> > from=::ffff:10.35.161.127,53512, >>>> >> > task_id=c70ace39-dbfe-4f5c-ae49-a1e3a82c >>>> >> > 2758 (api:46) >>>> >> > 2018-05-05 17:53:27,909+0300 INFO (vm/e6ce66ce) [root] >>>> >> > /usr/libexec/vdsm/hooks/before_device_create/10_allocate_net: rc=2 >>>> >> > err=vm >>>> >> > net allocation hook: [unexpected error]: Traceback (most recent >>>> call >>>> >> > last): >>>> >> > File "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_ne >>>> t", >>>> >> > line >>>> >> > 105, in <module> >>>> >> > main() >>>> >> > File "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_ne >>>> t", >>>> >> > line >>>> >> > 93, in main >>>> >> > allocate_random_network(device_xml) >>>> >> > File "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_ne >>>> t", >>>> >> > line >>>> >> > 62, in allocate_random_network >>>> >> > net = _get_random_network() >>>> >> > File "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_ne >>>> t", >>>> >> > line >>>> >> > 50, in _get_random_network >>>> >> > available_nets = _parse_nets() >>>> >> > File "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_ne >>>> t", >>>> >> > line >>>> >> > 46, in _parse_nets >>>> >> > return [net for net in os.environ[AVAIL_NETS_KEY].split()] >>>> >> > File "/usr/lib64/python2.7/UserDict.py", line 23, in __getitem__ >>>> >> > raise KeyError(key) >>>> >> > KeyError: 'equivnets' >>>> >> > >>>> >> > >>>> >> > (hooks:110) >>>> >> > 2018-05-05 17:53:27,915+0300 ERROR (vm/e6ce66ce) [virt.vm] >>>> >> > (vmId='e6ce66ce-852f-48c5-9997-5d2959432a27') The vm start process >>>> >> > failed >>>> >> > (vm:943) >>>> >> > Traceback (most recent call last): >>>> >> > File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line >>>> 872, >>>> in >>>> >> > _startUnderlyingVm >>>> >> > self._run() >>>> >> > File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line >>>> 2861, >>>> in >>>> >> > _run >>>> >> > domxml = hooks.before_vm_start(self._buildDomainXML(), >>>> >> > File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line >>>> 2254, >>>> in >>>> >> > _buildDomainXML >>>> >> > dom, self.id, self._custom['custom']) >>>> >> > File "/usr/lib/python2.7/site-packages/vdsm/virt/domxml_ >>>> preprocess.py", >>>> >> > line 240, in replace_device_xml_with_hooks_xml >>>> >> > dev_custom) >>>> >> > File "/usr/lib/python2.7/site-packages/vdsm/common/hooks.py", >>>> line >>>> 134, >>>> >> > in >>>> >> > before_device_create >>>> >> > params=customProperties) >>>> >> > File "/usr/lib/python2.7/site-packages/vdsm/common/hooks.py", >>>> line >>>> 120, >>>> >> > in >>>> >> > _runHooksDir >>>> >> > raise exception.HookError(err) >>>> >> > HookError: Hook Error: ('vm net allocation hook: [unexpected >>>> error]: >>>> >> > Traceback (most recent call last):\n File >>>> >> > "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_net", >>>> line >>>> >> > 105, in >>>> >> > <module>\n main()\n >>>> >> > File "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_ne >>>> t", >>>> >> > line >>>> >> > 93, in main\n allocate_random_network(device_xml)\n File >>>> >> > "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_net", >>>> line >>>> 62, >>>> >> > i >>>> >> > n allocate_random_network\n net = _get_random_network()\n File >>>> >> > "/usr/libexec/vdsm/hooks/before_device_create/10_allocate_net", >>>> line >>>> 50, >>>> >> > in >>>> >> > _get_random_network\n available_nets = _parse_nets()\n File >>>> "/us >>>> >> > r/libexec/vdsm/hooks/before_device_create/10_allocate_net", line >>>> 46, >>>> in >>>> >> > _parse_nets\n return [net for net in >>>> >> > os.environ[AVAIL_NETS_KEY].split()]\n File >>>> >> > "/usr/lib64/python2.7/UserDict.py", line 23, in __getit >>>> >> > em__\n raise KeyError(key)\nKeyError: \'equivnets\'\n\n\n',) >>>> >> > >>>> >> > >>>> >> > >>>> >> > Hence, the success rate was 28% against 100% running with d/s >>>> (d/s). >>>> If >>>> >> > needed, I'll compare against the latest master, but I think you get >>>> the >>>> >> > picture with d/s. >>>> >> > >>>> >> > vdsm-4.20.27-3.gitfee7810.el7.centos.x86_64 >>>> >> > libvirt-3.9.0-14.el7_5.3.x86_64 >>>> >> > qemu-kvm-rhev-2.10.0-21.el7_5.2.x86_64 >>>> >> > kernel 3.10.0-862.el7.x86_64 >>>> >> > rhel7.5 >>>> >> > >>>> >> > >>>> >> > Logs attached >>>> >> > >>>> >> > On Sat, May 5, 2018 at 1:26 PM, Elad Ben Aharon < >>>> [email protected]> >>>> >> > wrote: >>>> >> >> >>>> >> >> nvm, found gluster 3.12 repo, managed to install vdsm >>>> >> >> >>>> >> >> On Sat, May 5, 2018 at 1:12 PM, Elad Ben Aharon < >>>> [email protected] >>>> > >>>> >> >> wrote: >>>> >> >>> >>>> >> >>> No, vdsm requires it: >>>> >> >>> >>>> >> >>> Error: Package: vdsm-4.20.27-3.gitfee7810.el7.centos.x86_64 >>>> >> >>> (/vdsm-4.20.27-3.gitfee7810.el7.centos.x86_64) >>>> >> >>> Requires: glusterfs-fuse >= 3.12 >>>> >> >>> Installed: glusterfs-fuse-3.8.4-54.8.el7.x86_64 >>>> (@rhv-4.2.3) >>>> >> >>> >>>> >> >>> Therefore, vdsm package installation is skipped upon force >>>> install. >>>> >> >>> >>>> >> >>> On Sat, May 5, 2018 at 11:42 AM, Michal Skrivanek >>>> >> >>> <[email protected]> wrote: >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> On 5 May 2018, at 00:38, Elad Ben Aharon <[email protected]> >>>> wrote: >>>> >> >>>> >>>> >> >>>> Hi guys, >>>> >> >>>> >>>> >> >>>> The vdsm build from the patch requires glusterfs-fuse > 3.12. >>>> This >>>> is >>>> >> >>>> while the latest 4.2.3-5 d/s build requires 3.8.4 >>>> (3.4.0.59rhs-1.el7) >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> because it is still oVirt, not a downstream build. We can’t >>>> really >>>> do >>>> >> >>>> downstream builds with unmerged changes:/ >>>> >> >>>> >>>> >> >>>> Trying to get this gluster-fuse build, so far no luck. >>>> >> >>>> Is this requirement intentional? >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> it should work regardless, I guess you can force install it >>>> without >>>> >> >>>> the >>>> >> >>>> dependency >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> On Fri, May 4, 2018 at 2:38 PM, Michal Skrivanek >>>> >> >>>> <[email protected]> wrote: >>>> >> >>>>> >>>> >> >>>>> Hi Elad, >>>> >> >>>>> to make it easier to compare, Martin backported the change to >>>> 4.2 >>>> so >>>> >> >>>>> it >>>> >> >>>>> is actually comparable with a run without that patch. Would you >>>> >> >>>>> please try >>>> >> >>>>> that out? >>>> >> >>>>> It would be best to have 4.2 upstream and this[1] run to really >>>> >> >>>>> minimize the noise. >>>> >> >>>>> >>>> >> >>>>> Thanks, >>>> >> >>>>> michal >>>> >> >>>>> >>>> >> >>>>> [1] >>>> >> >>>>> >>>> >> >>>>> http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- >>>> demand-el7-x86_64/28/ >>>> >> >>>>> >>>> >> >>>>> On 27 Apr 2018, at 09:23, Martin Polednik < >>>> [email protected]> >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> On 24/04/18 00:37 +0300, Elad Ben Aharon wrote: >>>> >> >>>>> >>>> >> >>>>> I will update with the results of the next tier1 execution on >>>> latest >>>> >> >>>>> 4.2.3 >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> That isn't master but old branch though. Could you run it >>>> against >>>> >> >>>>> *current* VDSM master? >>>> >> >>>>> >>>> >> >>>>> On Mon, Apr 23, 2018 at 3:56 PM, Martin Polednik >>>> >> >>>>> <[email protected]> >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> On 23/04/18 01:23 +0300, Elad Ben Aharon wrote: >>>> >> >>>>> >>>> >> >>>>> Hi, I've triggered another execution [1] due to some issues I >>>> saw >>>> in >>>> >> >>>>> the >>>> >> >>>>> first which are not related to the patch. >>>> >> >>>>> >>>> >> >>>>> The success rate is 78% which is low comparing to tier1 >>>> executions >>>> >> >>>>> with >>>> >> >>>>> code from downstream builds (95-100% success rates) [2]. >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> Could you run the current master (without the dynamic_ownership >>>> >> >>>>> patch) >>>> >> >>>>> so that we have viable comparision? >>>> >> >>>>> >>>> >> >>>>> From what I could see so far, there is an issue with move and >>>> copy >>>> >> >>>>> >>>> >> >>>>> operations to and from Gluster domains. For example [3]. >>>> >> >>>>> >>>> >> >>>>> The logs are attached. >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> [1] >>>> >> >>>>> *https://rhv-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/rhv >>>> >> >>>>> -4.2-ge-runner-tier1-after-upgrade/7/testReport/ >>>> >> >>>>> <https://rhv-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/rhv >>>> >> >>>>> -4.2-ge-runner-tier1-after-upgrade/7/testReport/>* >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> [2] >>>> >> >>>>> https://rhv-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ >>>> >> >>>>> >>>> >> >>>>> rhv-4.2-ge-runner-tier1-after-upgrade/7/ >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> [3] >>>> >> >>>>> 2018-04-22 13:06:28,316+0300 INFO (jsonrpc/7) [vdsm.api] >>>> FINISH >>>> >> >>>>> deleteImage error=Image does not exist in domain: >>>> >> >>>>> 'image=cabb8846-7a4b-4244-9835-5f603e682f33, >>>> >> >>>>> domain=e5fd29c8-52ba-467e-be09-ca40ff054dd4' >>>> >> >>>>> from=: >>>> >> >>>>> :ffff:10.35.161.182,40936, >>>> >> >>>>> flow_id=disks_syncAction_ba6b2630-5976-4935, >>>> >> >>>>> task_id=3d5f2a8a-881c-409e-93e9-aaa643c10e42 (api:51) >>>> >> >>>>> 2018-04-22 13:06:28,317+0300 ERROR (jsonrpc/7) >>>> >> >>>>> [storage.TaskManager.Task] >>>> >> >>>>> (Task='3d5f2a8a-881c-409e-93e9-aaa643c10e42') Unexpected error >>>> >> >>>>> (task:875) >>>> >> >>>>> Traceback (most recent call last): >>>> >> >>>>> File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", >>>> line >>>> >> >>>>> 882, >>>> >> >>>>> in >>>> >> >>>>> _run >>>> >> >>>>> return fn(*args, **kargs) >>>> >> >>>>> File "<string>", line 2, in deleteImage >>>> >> >>>>> File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", >>>> line >>>> 49, >>>> >> >>>>> in >>>> >> >>>>> method >>>> >> >>>>> ret = func(*args, **kwargs) >>>> >> >>>>> File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", >>>> line >>>> >> >>>>> 1503, >>>> >> >>>>> in >>>> >> >>>>> deleteImage >>>> >> >>>>> raise se.ImageDoesNotExistInSD(imgUUID, sdUUID) >>>> >> >>>>> ImageDoesNotExistInSD: Image does not exist in domain: >>>> >> >>>>> 'image=cabb8846-7a4b-4244-9835-5f603e682f33, >>>> >> >>>>> domain=e5fd29c8-52ba-467e-be09-ca40ff054dd4' >>>> >> >>>>> >>>> >> >>>>> 2018-04-22 13:06:28,317+0300 INFO (jsonrpc/7) >>>> >> >>>>> [storage.TaskManager.Task] >>>> >> >>>>> (Task='3d5f2a8a-881c-409e-93e9-aaa643c10e42') aborting: Task >>>> is >>>> >> >>>>> aborted: >>>> >> >>>>> "Image does not exist in domain: 'image=cabb8846-7a4b-4244-9835 >>>> - >>>> >> >>>>> 5f603e682f33, domain=e5fd29c8-52ba-467e-be09-ca40ff054dd4'" - >>>> code >>>> >> >>>>> 268 >>>> >> >>>>> (task:1181) >>>> >> >>>>> 2018-04-22 13:06:28,318+0300 ERROR (jsonrpc/7) >>>> [storage.Dispatcher] >>>> >> >>>>> FINISH >>>> >> >>>>> deleteImage error=Image does not exist in domain: >>>> >> >>>>> 'image=cabb8846-7a4b-4244-9835-5f603e682f33, >>>> >> >>>>> domain=e5fd29c8-52ba-467e-be09 >>>> >> >>>>> -ca40ff054d >>>> >> >>>>> d4' (dispatcher:82) >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> On Thu, Apr 19, 2018 at 5:34 PM, Elad Ben Aharon >>>> >> >>>>> <[email protected]> >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> Triggered a sanity tier1 execution [1] using [2], which covers >>>> all >>>> >> >>>>> the >>>> >> >>>>> >>>> >> >>>>> requested areas, on iSCSI, NFS and Gluster. >>>> >> >>>>> I'll update with the results. >>>> >> >>>>> >>>> >> >>>>> [1] >>>> >> >>>>> https://rhv-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/4.2 >>>> >> >>>>> _dev/job/rhv-4.2-ge-flow-storage/1161/ >>>> >> >>>>> >>>> >> >>>>> [2] >>>> >> >>>>> https://gerrit.ovirt.org/#/c/89830/ >>>> >> >>>>> vdsm-4.30.0-291.git77aef9a.el7.x86_64 >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> On Thu, Apr 19, 2018 at 3:07 PM, Martin Polednik >>>> >> >>>>> <[email protected]> >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> On 19/04/18 14:54 +0300, Elad Ben Aharon wrote: >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> Hi Martin, >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> I see [1] requires a rebase, can you please take care? >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> Should be rebased. >>>> >> >>>>> >>>> >> >>>>> At the moment, our automation is stable only on iSCSI, NFS, >>>> Gluster >>>> >> >>>>> and >>>> >> >>>>> >>>> >> >>>>> FC. >>>> >> >>>>> Ceph is not supported and Cinder will be stabilized soon, >>>> AFAIR, >>>> >> >>>>> it's >>>> >> >>>>> not >>>> >> >>>>> stable enough at the moment. >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> That is still pretty good. >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> [1] https://gerrit.ovirt.org/#/c/89830/ >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> Thanks >>>> >> >>>>> >>>> >> >>>>> On Wed, Apr 18, 2018 at 2:17 PM, Martin Polednik >>>> >> >>>>> <[email protected] >>>> >> >>>>> > >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> On 18/04/18 11:37 +0300, Elad Ben Aharon wrote: >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> Hi, sorry if I misunderstood, I waited for more input regarding >>>> what >>>> >> >>>>> >>>> >> >>>>> areas >>>> >> >>>>> have to be tested here. >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> I'd say that you have quite a bit of freedom in this regard. >>>> >> >>>>> >>>> >> >>>>> GlusterFS >>>> >> >>>>> should be covered by Dennis, so iSCSI/NFS/ceph/cinder with some >>>> >> >>>>> suite >>>> >> >>>>> that covers basic operations (start & stop VM, migrate it), >>>> >> >>>>> snapshots >>>> >> >>>>> and merging them, and whatever else would be important for >>>> storage >>>> >> >>>>> sanity. >>>> >> >>>>> >>>> >> >>>>> mpolednik >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> On Wed, Apr 18, 2018 at 11:16 AM, Martin Polednik < >>>> >> >>>>> [email protected] >>>> >> >>>>> > >>>> >> >>>>> >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> On 11/04/18 16:52 +0300, Elad Ben Aharon wrote: >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> 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. >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> Any update on this? I believe the gluster tests were >>>> successful, >>>> >> >>>>> OST >>>> >> >>>>> >>>> >> >>>>> passes fine and unit tests pass fine, that makes the storage >>>> >> >>>>> backends >>>> >> >>>>> test the last required piece. >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> On Wed, Apr 11, 2018 at 4:38 PM, Raz Tamir <[email protected] >>>> > >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> +Elad >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> On Wed, Apr 11, 2018 at 4:28 PM, Dan Kenigsberg < >>>> [email protected] >>>> >> >>>>> >>>> >> >>>>> > >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> On Wed, Apr 11, 2018 at 12:34 PM, Nir Soffer < >>>> [email protected]> >>>> >> >>>>> wrote: >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> On Wed, Apr 11, 2018 at 12:31 PM Eyal Edri <[email protected]> >>>> >> >>>>> >>>> >> >>>>> 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 < >>>> >> >>>>> [email protected] >>>> >> >>>>> > >>>> >> >>>>> >>>> >> >>>>> 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 >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> _______________________________________________ >>>> >> >>>>> Devel mailing list >>>> >> >>>>> [email protected] >>>> >> >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>> >>>> >> >> >>>> >> > >>>> >> > <logs.tar.gz> >>>> >> > >>>> >> > >>>> > >>>> > >>>> >>>> >
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/CICMYRFHTGMQOW6FLGMBCW3MEFE2OXHM/
