max virtio slots value for instances aren't maintained on resize

Bug #1722923 reported by Matt Rabe
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
nova-powervm
Fix Released
Undecided
Matt Rabe

Bug Description

The DefaultStandardize object in pypowervm defaults the max virtio slots value to 64. nova-powervm always creates the DefaultStandardize object with this default which means that on every resize operation nova-powervm will always attempt to set the value to be 64.

Matt Rabe (mdrabe)
Changed in nova-powervm:
assignee: nobody → Matt Rabe (mdrabe)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova-powervm (master)

Fix proposed to branch: master
Review: https://review.openstack.org/511343

Changed in nova-powervm:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova-powervm (master)

Reviewed: https://review.openstack.org/511343
Committed: https://git.openstack.org/cgit/openstack/nova-powervm/commit/?id=4bad1ec1654b757c70100fbcc6f51505719d79d9
Submitter: Zuul
Branch: master

commit 4bad1ec1654b757c70100fbcc6f51505719d79d9
Author: mdrabe <email address hidden>
Date: Wed Oct 11 16:03:36 2017 -0500

    Persist existing LPAR wrapper attributes in DefaultStandardize on resize

    The DefaultStandardize object in pypowervm defaults the proc units
    factor, max virtio slots, uncapped weight, spp, availability
    priority, srr, proc compat, and lpar metric values. nova-powervm
    does not pass in these parameters when resizing.

    This results in these attributes being set to the default defined
    by the DefaultStandardize object for every resize operation. This
    change passes those parameters into the DefaultStandardize object.

    Note that if the attributes were passed in as part of the flavor
    then the flavor's values would be set later in the DefaultStandardize
    object by the LPARBuilder.

    Closes-Bug: #1722923
    Change-Id: I0e9ad0dbbc35658e096636a454ad493492025420

Changed in nova-powervm:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova-powervm (stable/pike)

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/514858

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova-powervm (stable/pike)

Change abandoned by Matt Rabe (<email address hidden>) on branch: stable/pike
Review: https://review.openstack.org/514858
Reason: pypowervm requirement is not met in Pike.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova-powervm (stable/pike)

Reviewed: https://review.openstack.org/514858
Committed: https://git.openstack.org/cgit/openstack/nova-powervm/commit/?id=9e553a8659d3c53deb36086b00da10717fd2f57a
Submitter: Zuul
Branch: stable/pike

commit 9e553a8659d3c53deb36086b00da10717fd2f57a
Author: mdrabe <email address hidden>
Date: Wed Oct 11 16:03:36 2017 -0500

    Persist existing LPAR wrapper attributes in DefaultStandardize on resize

    The DefaultStandardize object in pypowervm defaults the proc units
    factor, max virtio slots, uncapped weight, spp, availability
    priority, srr, and proc compat (note that the enable lpar metric
    parameter isn't included in this stable/pike commit as the minimum
    pypowervm requirement for Pike does not support that parameter).
    nova-powervm does not pass in these parameters when resizing.

    This results in these attributes being set to the default defined
    by the DefaultStandardize object for every resize operation. This
    change passes those parameters into the DefaultStandardize object.

    Note that if the attributes were passed in as part of the flavor
    then the flavor's values would be set later in the DefaultStandardize
    object by the LPARBuilder.

    Closes-Bug: #1722923
    Change-Id: I0e9ad0dbbc35658e096636a454ad493492025420
    (cherry picked from commit 4bad1ec1654b757c70100fbcc6f51505719d79d9)

tags: added: in-stable-pike
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.