Steven Hardy [Mon, 8 Apr 2013 13:53:04 +0000 (14:53 +0100)]
heat api : Update ec2token middleware for v4 signatures
Update ec2token so it can verify v4 signature formats.
Note for v4 signatures to work you currently need to install
the latest python-keystoneclient, as no release yet contains
patch ref https://review.openstack.org/#/c/26013/
This change should be backwards compatible, as older keystoneclient
versions will simply ignore the additional request keys
Re-work run_tests.sh to call testr instead of nose
Running testr directly or running the tests in tox are the preferred
method at this point, but developers may still have automation around
run_tests.sh.
Remove use of nose attrib plugin and most unittest
Some simple cases that do not use mox still use unittest directly.
Replacing unittest.TestCase with HeatTestCase has the added benefit of
capturing all logging for reporting during failure.
A new base class for tests is used to reduce repetitive steps used in
a majority of tests. This new base class also uses fixtures.FakeLogger
to suppress logging, though it will be shown on any failures to aid in
debugging the failure.
Prints that happen on normal operation of the test suite are all removed
as they are not needed and only clutter the output.
These tests are not unit tests, and take a long time. They are being
moved into tempest, which is where integration/functional tests live in
OpenStack.
With the migration to testrepository, many of the instructions are
obsolete. Also the examples are not needed as we have plenty of fine
examples available in the code itself.
This also disables the functional tests from running. The code is still
left here for posterity. These are intended to be moved into tempest
test cases and thus will be removed entirely at that time.
At the moment, we will just run each co-routine to completion, but in
future we can use this to return control to the caller so that resources
may be created in parallel.
Steven Hardy [Tue, 30 Apr 2013 09:38:04 +0000 (10:38 +0100)]
heat api: fix ec2token authentication
Since the change merged from https://review.openstack.org/#/c/27383/
ec2token auth no longer works, because there is a mismatch between
the config file section name and the section specified in ec2token
This is currently broken since heat-engine always listens to the
'engine' topic and there isn't actually a good use case for this to be
configurable, so let's kill it.
We currently send engine RPCs to the 'engine.$host' topic means that
it is impossible to run heat-api and heat-engine on different
machines because you can't configure heat-api with the hostname of
heat-engine.
Fix this simply by sending RPCs to 'engine' which heat-engine. We have
always listened on this topic, so there is no backwards compat
concerns.
This is somewhat related to the multiple-engines blueprint, but
doesn't really help or hinder it.
The structure of the program is compromised by doing too much logic in
the import phase. We can read the code more cleanly if we can see where
the intended initialization code is called. This may make tests slightly
more tedious to write, but that should be handled by writing generic
fixtures which can be reused for exactly this purpose.
Previously resources would be left in the CREATE_IN_PROGRESS state in the
event of a timeout or the thread being cancelled (due to a delete being
requested while the stack was still being created). We should instead put
these resources into the CREATE_FAILED state when this occurs, thus
creating an event with the reason.
We don't want to store any state in the Instance object, instead take
advantage of the new mechanism whereby the result of handle_create() is
passed to check_active().
This makes the autoscaling code uglier for now (since it must still store
the instance state in the instance), but this will go away when we move to
using co-routines to create resources in parallel.
Steve Baker [Mon, 8 Apr 2013 03:47:46 +0000 (15:47 +1200)]
Remove service _user, _password, _tenant from context
These are not currently used anywhere in heat-engine, and I'm
not comfortable with the service password going over the (controller)
network.
If heat-engine needs access to these in the future then they can always
be configured in heat-engine.conf, or the operation can be performed
in the api and the results put into the context.
Steve Baker [Tue, 2 Apr 2013 23:29:50 +0000 (12:29 +1300)]
Move heat-api auth_token conf from paste.ini
keystone auth_token middleware now allows heat to have auth_token
configuration in heat-api.conf. Moves the example of
auth_token configuration from heat-api-paste.ini to heat-api.conf.
This simplifies user configuations and users is no longer required
to edit heat-api-paste.ini.
This does not break backward compatibility. auth_token first
tries the configurations in /etc/heat/heat-api-paste.ini and then the
above configurations. Thus a user who already uses heat-api-paste.ini
does not need to change it.
Steve Baker [Mon, 8 Apr 2013 03:35:55 +0000 (15:35 +1200)]
Subclass keystone middleware to set headers
Replace old forked auth_token with a subclass
of keystoneclient middleware.
The advantages of moving to keystoneclient middleware:
- can use v3 (or v2) keystone api
- PKI tokens
- token revocation
The subclass sets the following headers to be consumed by our
request context filter:
- X-Admin-User
- X-Admin-Pass
- X-Admin-Tenant-Name
- X-Auth-Url
The need to override _build_user_headers should be a short-term thing,
X-Admin-* isn't actually used currently, and there are a few options
that need to be discussed for getting X-Auth-Url to the engine.
Mark McLoughlin [Mon, 22 Apr 2013 10:12:58 +0000 (11:12 +0100)]
Simplify rpc client calls
We always pass host=None to _engine_topic() which means that we always
construct a topic using CONF.engine_topic and CONF.host.
And since RpcProxy methods falls back to the topic supplied to its
constructor, we never need to explicitly pass it.
We can safely remove the _engine_topic() method and the passing of an
explicit topic to RpcProxy methods and replace it with constructing the
correct topic at construction time, without causing any functional
changes.
While we're at it, replace the last use of the variable name FLAGS with
CONF.
OpenShift Origin images require a lot of packages. So, although the OpenShift
Origin HEAT template can be adapted to run with JEOS images, they would take
> 25 min to spin up. Instead, I have opted to create heavier images to speed up
machine creation. @See https://github.com/sdake/heat-jeos/pull/49
Avoid storing the state of instances that are currently being created in
the instance group resource itself. Instead, ensure that they are returned
from handle_create() and take advantage of that result being passed back in
to check_active().
All resources that implement check_active() will require some state to be
retained from the call to handle_create(). Saving this as state in the
Resource object results in repeated, ugly, and potentially error-prone
code.
Instead, allow a subclass-defined state object returned from
handle_create() to be passed to check_active(). This ensures that the state
is limited in scope to where it is meaningful (during the create
operation), and that it will be garbage-collected at the appropriate time,
even if an unexpected exception occurs e.g. because a thread is cancelled.
Steven Hardy [Mon, 8 Apr 2013 17:20:43 +0000 (18:20 +0100)]
heat : Getting started updates for grizzly
Update GettingStarted to drop references to F16/essex and add the
password sed which is required when running grizzly installed via
tools/openstack on Fedora
If an AccessKey could not be created, it also could not be deleted. This
change allows deletion of the resource to proceed even if the user does not
exist.
Code Review / openstack-build / heat-build.git / log