Bug 1261092

Summary:	Rbd backend doesn't support disk IO qos
Product:	Red Hat OpenStack	Reporter:	Stephen Gordon <sgordon>
Component:	openstack-nova	Assignee:	Eoghan Glynn <eglynn>
Status:	CLOSED ERRATA	QA Contact:	Yogev Rabl <yrabl>
Severity:	high	Docs Contact:
Priority:	high
Version:	8.0 (Liberty)	CC:	berrange, dasmith, eglynn, jschluet, kchamart, ndipanov, sbauza, sferdjao, sgordon, vromanso, yeylon, yrabl
Target Milestone:	beta	Keywords:	FutureFeature, TestOnly
Target Release:	8.0 (Liberty)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-nova-12.0.0-1.el7ost	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-07 21:07:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1262069

Description Stephen Gordon 2015-09-08 14:44:54 UTC

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

Comment 3 Yogev Rabl 2015-11-23 09:10:59 UTC

verified in version 
openstack-nova-api-12.0.0-2.el7ost.noarch
openstack-nova-compute-12.0.0-2.el7ost.noarch

Comment 4 Stephen Gordon 2015-12-04 16:56:03 UTC

Hi Yogev,

Can you confirm this is now part of the automation suite?
Thanks,

Steve

Comment 5 Yogev Rabl 2015-12-06 08:54:39 UTC

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.

Comment 6 Stephen Gordon 2015-12-11 17:28:19 UTC

(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.

Comment 7 Yogev Rabl 2015-12-13 11:51:41 UTC

(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?

Comment 8 Stephen Gordon 2015-12-18 19:01:22 UTC

(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.

Comment 9 Yogev Rabl 2015-12-20 12:21:34 UTC

(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.

Comment 10 Yogev Rabl 2015-12-20 12:21:47 UTC

(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.

Comment 12 errata-xmlrpc 2016-04-07 21:07:30 UTC

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