Ask Your Question
0

filter scheduler debug question

asked 2014-03-17 09:42:57 -0500

markusleb gravatar image

Hi!

I have built a Havana infrastructure with two compute nodes of which one is using trusted boot via Intel Trusted Execution Technology. So far, I have been successful in deploying Havana, OpenAttestation 2.1, and have configured the nova.conf [trusted_computing] section appropriately. I have registered my tboot host in the OAT portal successfully and can get attestation results manually from my controller node via wget. I am also fairly sure that I have no certificate errors in my setup. Still, scheduling an instance with the flavor extra spec trust:trusted_host returns with an instance state ERROR. (Non-trusted instances are spawned without issues.)

Investigating this, I have now both looked into the nova scheduler log (verbose debug True) and into the tomcat access log of OAT. What I have noticed is that the scheduler seems to run through all filters with success, returning my two hosts, but the trusted_filter immediately returns zero hosts without further comment. The tomcat access log reveals that OAT is never queried by the controller node, so I am at loss what is going on. I would appreciate any pointer where / how to look further, specifically if any sort of logging output of the trusted_filter can be enabled.

I noticed that there is a caching mechanism inside the trusted_filter.py module but not being a Python expert I do not know how to turn it off, just in case.

Thanks, Markus

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
0

answered 2014-03-19 08:42:32 -0500

markusleb gravatar image

In the spirit of self-answering my question, here's how I finally solved it:

First thing was a certificate format error: OAT being a JDK project creates jks-formatted keys/certs. OpenStack requires PEM formats, however. I had reused the jks-formatted certificate that was used to access OAT from the trust agents but needed to use a PEM certificate to access OAT from my control node.

Second thing was a name resolution error on the OAT node. During the trusted_filter run it is not enough to have the compute nodes registered in OAT by ip address. Compute node names in OAT must resolve to exactly the same names in the Nova controller and vice versa.

Pretty dumb mistakes that I only found by trial and error in the end. Would be great if the trusted_filter gave more then a plain "ERROR" state for root-causing...

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2014-03-17 09:42:57 -0500

Seen: 513 times

Last updated: Mar 19 '14