Boris-Michel, One thing that I noticed was a typo: schedulre that can cause malfunction. I am not sure what version you are using, but recently the extra_spec checking is moved to compute_capabilities_filter.py (ComputeCapabilitiesFilter). As far as I understand, the current ComputeFilter does not check extra_specs.
Thanks, Joseph ---- (w) 703-248-6160 (c) 571-340-2434 (f) 703-812-3712 http://www.east.isi.edu/~jsuh Information Sciences Institute University of Southern California 3811 N. Fairfax Drive Suite 200 Arlington, VA, 22203, USA ----- Original Message ----- From: "Boris-Michel Deschenes" <boris-michel.desche...@ubisoft.com> To: openstack@lists.launchpad.net Sent: Thursday, August 9, 2012 11:10:15 AM Subject: [Openstack] using extra specs Hi guys, I currently have a working cloud with a working GPU passthrough setup (CentOS/libvirt/Xen 4.1.2), now I need to work on adding this new resource to openstack. Here is the plan: 1. Create a new instance type (g1.small) with an extra spec like “xpu_arch = radeon” 2. Modify the compute side so that nova-compute publishes this new capability I’m in between step 1 and step 2, so normally, when I try and launch a VM with the new instance type, the scheduling should fail since there is no compute node publishing this capability yet, but the scheduling does go through despite having the ComputeFilter available. My understanding is that by having: scheduler_available_filters=nova.schedulre.filters.standard_filters scheduler_default_filters=ComputeFilter The ComputeFilter should try and ensure that the hosts satisfies the extra specs but the filter is not doing its job since the VM is scheduler and casted to the compute node although it does not advertise any of the extra spec. The extra spec is definitely part of the instance_type, I can see it in the scheduler log: (TRUNCATED) u'8895af5063b176bef97ab81f076d57f3', u'min_disk': u'0', u'is_public': True, u'deleted_at': None, u'properties': {u'os_type': u'windows'}, u'size': 9256562688}, u'instance_type': {u'root_gb': 0, u'deleted_at': None, u'name': u'g1.small', u'deleted': False, u'created_at': u'2012-08-08 18:33:29', u'ephemeral_gb': 0, u'updated_at': None, u'memory_mb': 2048, u'vcpus': 1, u'extra_specs': {u'xpu_arch': u'radeon'}, u'swap': 0, u'rxtx_factor': 1.0, u'flavorid': u'105', u'vcpu_weight': None, u'id': 6}, u'instance_properties': {u'vm_state': u'building', u'availability_zone': (TRUNCATED) So again, this VM should not be casted to any compute node and the scheduler should complain about no host having the required capability but it does not… the VM is instantiated on the one compute node even though it never published the required capability. It looks like the ComputeFilter is either not used properly or I’m missing something. Basically I want the scheduler to fail when I launch the VM before I start working on step 2. Any help appreciated. Boris _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
