I was previously ignoring an invalid or inaccessible image but
I think this should instead be a hard failure. How can a user
request an image create in nova with an image that can't be read?
I also noticed that it was possible for any test looking for a
raised error to fail if that exception wasn't raised so
assert(False) in that case.
This was requested by the puppet team for inclusion in the
puppet-nova module. It does make a certain amount of sense for
all nova-type configuration to exist in a single place.
oslo.config isn't really made to handle this type of thing. If
project='nova' and prog='join' it would still find
/etc/nova/nova.conf first and try to load that instead. So I
had to duplicate some of the oslo.config code and hard code
nova and join in order to simulate the previous behavior but
work for my purposes.
The original location, /etc/join/join.conf, is the final
fallback to support any existing installations.
flake8 is quite a bit more picky and discovered a lot of
issues.
Don't let missing configuration blow things up in order to be
able to run unit tests.
Hacky workaround for missing ipalib/ipapython in PyPy
The authentication scheme of the REST API is still a bit up
in the air so switch this to not rely/expect authentication
but instead to use the nova service user to talk to other
services.
Eventually this should use its own service user.
This enables us to get images from glance but also to handle
looking up the information we need when Neutron assigns a
floating IP address. This means we can create the hostname
in IPA DNS in advance so it will be on the public network
and not the private one.
Add a new middleware to get the Keystone token from the auth
headers.
Add a simple glance client to retrieve image metadata.
Update the default paste configuration to require auth and
make a copy of the token for internal use.
This is based heavily on the WSGI code in cinder.
There are two services: a REST service and a notification
listener.
Currently both log only to stdout.
The configuration file join.conf controls the REST service.
nova configuration should look like this (assuming the REST
service is running on the nova compute host).
vendordata_providers = StaticJSON, DynamicJSON
vendordata_dynamic_targets = 'join@http://127.0.0.1:9999/v1/'
vendordata_driver = nova.api.metadata.vendordata_http.HTTPFileVendorData
vendordata_dynamic_connect_timeout = 5
vendordata_dynamic_read_timeout = 30
vendordata_jsonfile_path = /etc/nova/cloud-config.json
For the notification service like this:
notification_driver = messaging
notification_topic = notifications
notify_on_state_change = vm_state
Authentication is disabled in api-paste.ini for now.
Harry Rybacki