yahoo-eng-team team mailing list archive

[OpenStack Hudson <1129485@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/23454
Committed: http://github.com/openstack-dev/devstack/commit/2920b7decc6769707ea45552c94864701c55988e
Submitter: Jenkins
Branch:    master

commit 2920b7decc6769707ea45552c94864701c55988e
Author: Devananda van der Veen <devananda.vdv@xxxxxxxxx>
Date:   Mon Mar 4 11:47:14 2013 -0800

    Stash baremetal deploy image IDs in a namespace.
    
    Baremetal PXE driver should read deploy_kernel_id & deploy_ramdisk_id
    from the 'baremetal:' namespace within instance_type['extra_specs']
    so that it doesn't conflict with ComputeCapabilitiesFilter any more.
    
    This allows nova-compute to use ComputeCapabilitiesFilter with baremetal
    again. For this filter to properly match the baremetal ndoe's RAM,
    we need to tune two other Nova options for physical hardware.
    
    Fixes bug 1129485.
    
    Change-Id: I0aa1b0fef8ac59a06217577af8c747437d2d6bf5


** Changed in: devstack
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1129485

Title:
  ComputeCapabilitiesFilter does not play well with baremetal driver

Status in devstack - openstack dev environments:
  Fix Released
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Manuals:
  Confirmed

Bug description:
  When using the baremetal driver and the default nova scheduler
  filters, the scheduler will always fail to find a suitable host.

  In order to provision baremetal instances, a separate deploy kernel &
  ramdisk are used. These may be specified on the flavor (instance_type)
  extra_specs so that an environment may support different deployment
  processes (eg, for multiple arch support). However, the
  ComputeCapabilitiesFilter will not match the instance_type to any
  compute host that is not publishing all of the same extra_specs, and
  in the baremetal case, none of the compute hosts publish these
  deploy_kernel / deploy_ramdisk specs (precisely because they are
  properties of the flavor, not the compute host).

  The simple workaround for this is to disable the
  ComputeCapabilitiesFilter, while leaving all other default filters
  enabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1129485/+subscriptions