openstack team mailing list archive

[Joseph Suh <jsuh@xxxxxxx>]

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.deschenes@xxxxxxxxxxx>
To: openstack@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp