Bug 1329289 - Need process and tooling for machine type and device checking after new QEMU version
Summary: Need process and tooling for machine type and device checking after new QEMU ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Yash Mankad
QA Contact: huiqingding
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-21 14:26 UTC by Markus Armbruster
Modified: 2017-12-20 21:32 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-15 00:22:26 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Markus Armbruster 2016-04-21 14:26:18 UTC
A rebase can easily introduce unwanted changes to stable interfaces.
To avoid that, we need to find and review interface differences.

Machine type and device configuration is one such interface.  We need
to review:

- Semantics of machine types

  Machine types set configuration variables, including qdev
  compat_props.  Any new variables?  Lost ones?  Replaced ones?
  Changed values?

  This is entirely manual.

- Devices

  Any new devices?  Lost ones?

  Unwanted devices need to be cut or made inaccessible.

  Finding available devices manually is too error-prone.  Use
  introspection.  In modern QEMU: qom-list-types.

- Device properties

  Any new devices?  Lost ones?

  Finding available properties manually even more error-prone than
  devices.  In modern QEMU: device-list-properties.  Note that it
  doesn't work for some devices.

- Changed property types

  This should be rare.  The type returned by device-list-properties
  should do.

- Changed property default values

  We lack a way to introspect the default value.

  Long term, upstream introspection should be extended to cover this.

  Short term, we may have to settle for a downstream hack.

  Note that default values may depend on the machine type.

The checking is the same for major and minor releases.  The difference
is in the kind of changes we accept.

The review should produce a document detailing the changes.  For each
change, explain whether its wanted or not, and why.  For unwanted
changes, point to a BZ.

We need tooling to automate gathering the data to review.

Comment 7 Miroslav Rezanina 2017-12-15 14:44:58 UTC
Currently, there's rebase verification checklist for this. We need to assing machine type owner for each architecture that will be responsible (leader) for post-rebase testing and implementation (new machine types has own bz).


Note You need to log in before you can comment on or make changes to this bug.