Red Hat Bugzilla – Bug 1261092
Rbd backend doesn't support disk IO qos
Last modified: 2016-04-07 17:07:30 EDT
Cloned from launchpad bug 1405367. Description: Honor https://wiki.openstack.org/wiki/InstanceResourceQuota#IO_limits by propagating the extra_specs also in the RBD sub-class. Specification URL (additional information): https://bugs.launchpad.net/nova/+bug/1405367
verified in version openstack-nova-api-12.0.0-2.el7ost.noarch openstack-nova-compute-12.0.0-2.el7ost.noarch
Hi Yogev, Can you confirm this is now part of the automation suite? Thanks, Steve
Hi Steve, This test is not a part of the automation suite yet. This test requires some manual handling in order to monitor the I/O of the instances.
(In reply to Yogev Rabl from comment #5) > Hi Steve, > > This test is not a part of the automation suite yet. This test requires some > manual handling in order to monitor the I/O of the instances. Is there anything we can do about this? A key metric for the OSP-8 release is that features be tested via automation, otherwise we can't call them out. This is to ensure that we also regression test this functionality in future releases.
(In reply to Stephen Gordon from comment #6) > (In reply to Yogev Rabl from comment #5) > > Hi Steve, > > > > This test is not a part of the automation suite yet. This test requires some > > manual handling in order to monitor the I/O of the instances. > > Is there anything we can do about this? A key metric for the OSP-8 release > is that features be tested via automation, otherwise we can't call them out. > This is to ensure that we also regression test this functionality in future > releases. We can set all the necessary requirements for this feature and check they are configured in the VM's XML configuration file and trust KVM to work properly. I wounldn't be happy with that test, but if you'd like I can set this test in the Acceptance test plan for Ceph integration with Openstack and test it every major version/release candidate. Is this agreeable?
(In reply to Yogev Rabl from comment #7) > (In reply to Stephen Gordon from comment #6) > > (In reply to Yogev Rabl from comment #5) > > > Hi Steve, > > > > > > This test is not a part of the automation suite yet. This test requires some > > > manual handling in order to monitor the I/O of the instances. > > > > Is there anything we can do about this? A key metric for the OSP-8 release > > is that features be tested via automation, otherwise we can't call them out. > > This is to ensure that we also regression test this functionality in future > > releases. > > We can set all the necessary requirements for this feature and check they > are configured in the VM's XML configuration file and trust KVM to work > properly. > > I wounldn't be happy with that test, but if you'd like I can set this test > in the Acceptance test plan for Ceph integration with Openstack and test it > every major version/release candidate. > > Is this agreeable? Yes, this seems appropriate. Responsibility for regression testing of KVM itself really falls to Virt QE.
(In reply to Stephen Gordon from comment #8) > (In reply to Yogev Rabl from comment #7) > > (In reply to Stephen Gordon from comment #6) > > > (In reply to Yogev Rabl from comment #5) > > > > Hi Steve, > > > > > > > > This test is not a part of the automation suite yet. This test requires some > > > > manual handling in order to monitor the I/O of the instances. > > > > > > Is there anything we can do about this? A key metric for the OSP-8 release > > > is that features be tested via automation, otherwise we can't call them out. > > > This is to ensure that we also regression test this functionality in future > > > releases. > > > > We can set all the necessary requirements for this feature and check they > > are configured in the VM's XML configuration file and trust KVM to work > > properly. > > > > I wounldn't be happy with that test, but if you'd like I can set this test > > in the Acceptance test plan for Ceph integration with Openstack and test it > > every major version/release candidate. > > > > Is this agreeable? > > Yes, this seems appropriate. Responsibility for regression testing of KVM > itself really falls to Virt QE. Agreed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0603.html