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.
Steve Baker [Wed, 27 Mar 2013 20:29:38 +0000 (09:29 +1300)]
Allow cinder operations with only auth_token
This uses the same technique as Horizon for auth_token operations.
Specifically, the cinder endpoint is found directly from keystone
and the auth_token and management_url are set on cinderclient
after it has been created.
Client libs are in theory capable of looking up their own endpoints
given an auth_token, but in practice this is the code-path least
travelled and there are many issues. I think it is best to do what
Horizon does, since all Horizon operations use only a token and always
provide the endpoint to the client lib.
Tested by launching a stack with and without the --token-only flag
Also tested using Horizon, which is auth_token only
Since the change implemented as part of bug #1136148 we no longer
wait for nova to create the instance before reloading the loadbalancer
which means we race nova assigning an IP to the instance and typically
the loadbalancer config ends up with the 0.0.0.0 default value
which the loadbalancer implementation uses when nova returns no IP.
This patch moves the LB reload into a separate function, which is called
after instances are active on group creation or adjustment
Since our loadbalancer is broken without this fix, this is a candidate
for backporting to grizzly milestone-proposed.
Steve Baker [Tue, 26 Mar 2013 04:11:47 +0000 (17:11 +1300)]
Fix swift client token authentication
Triggered by launching a stack containing swift containers
through Horizon.
The swift client does its own endpoint lookup if we don't know
it, so we don't have to do it ourselves. Also, our endpoint lookup
was broken in the auth_token codepath.
Currently the engine validate_template returns cfn formatted
Parameters from the template, which isn't actually very useful
to build a full UI from a validate call.
This change returns the original Parameters template snippet
and changes the cfn api to reformat to the CFN API legacy format.
The Parameters section of the RPC and the REST APIs now return
a dictionary containing the parameters as specified in the template.
Previously the Parameters section contained a list in the CFN API
format.
Pseudo parameters are filtered out of the validate results.
Steve Baker [Sun, 17 Mar 2013 20:21:35 +0000 (09:21 +1300)]
Create a wsgi factory method for Debug filter.
This can be enabled by putting the following in the *-paste.ini
file:
[filter:debug]
paste.filter_factory = heat.common.wsgi:filter_factory
heat.filter_factory = heat.common.wsgi:debug_filter
Steven Dake [Sat, 16 Mar 2013 20:37:29 +0000 (13:37 -0700)]
If a stack create fails, ensure the stack is deleteable
The resource delete operation attempts to delete CREATE_FAILED
resources. Further it attempts to delete resources that were
not created during a creation operation because further processing
of the template does not take place.
This patch special cases these two conditions in the delete operation.
Code Review / openstack-build / heat-build.git / log