Using the latest Nova Ironic compute drivers (either from Ironic or Nova) I'm hitting scheduling ERRORS:
Sep 08 15:26:45 localhost nova-scheduler[29761]: 2014-09-08 15:26:45.620 29761 DEBUG nova.scheduler.filters.compute_capabilities_filter [req-9e34510e-268c-40de-8433-d7b41017b54e None] extra_spec requirement 'amd64' does not match 'x86_64' _satisfies_extra_specs /opt/stack/venvs/nova/lib/python2.7/site-packages/nova/scheduler/filters/compute_capabilities_filter.py:70
I've gone ahead and patched in https://review.openstack.org/#/c/117555/.
The issue seems to be that ComputeCapabilitiesFilter does not itself canonicalize instance_types when comparing them which will breaks existing TripleO baremetal clouds using x86_64 (amd64).
Ah, so when returning a dict from get_available_ resources, the Ironic driver is reporting the compute host architecture in two places
- The 'supported_ instances' list ( [[<arch>, <vmmode>, <hvtype>]])
- The 'cpu_arch' extra specs field
Then the filter is matching on the extra specs field.
The canonicalization of architecture and back compat workarounds I put in place were only targetting the 'supported_ instances' list information.
The failure you're reporting here is because we canonicalized the data put into the extra spec, but don't canonicalize the data when checking it in the ComputeCapabili tiesFilter
I don't know much about Ironic, but I'm curious as to why it is reporting a cpu_arch extra specs field at all, given that we already have a well specified way to report the architecture via the 'supported_ instances' list and the ImageProperties Filter filter which AFAICT should serve the same purpose.
So I can see 3 possible fixes here, in order of my preference
- Remove the cpu_arch extra_specs entirely and just use ImageProperties Filter instead instances) tiesFilter to canonicalize match data when looking at 'cpu_arch' extra_spec
- Stop canonicalizing the data in the 'cpu_arch' extra specs field (but *still* canonicalize supported_
- Add hack to ComputeCapabili