We return back the sensitive information to user
when some exceptions happened, for example,
when DBError happened, we return the whole sql
statement to user, it's not safe.
This patch changes to return the message if the
exception is the HeatException, otherwise the message
won't be revealed to user.
We already have REST api support for cancelling a
UPDATE_IN_PROGRESS stack with rollback. This adds a
new action 'cancel_without_rollback' to allow for
canceling a create/update in_progress stack without
Add converge parameter for stack update API and RPC call,
that allow triggering observe on reality. This will be
triggered by API call with converge argument (with True
or False value) within. This flag also works for resources
within nested stack.
Implements bp get-reality-for-resources
Where strings are continued across multiple lines, it's easy to miss a
space. This fixes several incorrect strings, cleans up some formatting
(don't line break inside a format specifier) and fixes typos.
It's possible that we could end up with multiple resources with the same
physical resource ID, but that would be undetectable since we return only
one from the database layer. This change allows us to detect the problem an
return an error where the result is rendered ambiguous.
Ignore merged environment from the client, if there are
'environment_files' in the request for merging in the server.
This would avoid the duplicates when 'parameter_merge_strategies'
are specified in the first env file.
Add 'with_condition_func' filter param for API
template-function-list, if the param set to true,
the response will include the condition functions.
We can use admin_context to have access to stacks
and software configs across projects. This removes
the tenant_safe flag from rpc and db api. This is
backward compatible with older rpc clients.
We still support use of global_tenant flag for listing
stacks and software configs. However, by default
an admin(user with admin role in admin_project)
would not need that.
Passing empty section like parameters in the environment can leave the
user with a strange error message. This fixes the issue by providing a
Service's _get_stack method already checks
whether the stack is None and if it is, throws
an exception. So methods that use _get_stack
do not need to check the same thing.
Also, looks like there is no way that stack's
self.raw_template.template or self.raw_template.template
can be None or blank, so removed such checks as well
with corresponding tests.
Similar to the recent addition that enables retrieval of the current
environment for a stack, this enables reading the current files map
for a running stack, which is useful if you want to introspect the
current state, and/or deploy another similar stack without necessarily
having the exact command/repo used initially.
Implements: blueprint files-show
The GET call to list events will support a nested_depth parameter. The
response will have an additional links url with the ref 'root_stack'
to indicate that this API supports nested_depth queries.
This has the following consequences for old/new combinations of
- new heatclient, new server - nested_depth param is set, server
returns nested events
- new heatclient, old server - nested_depth param is set, server
returns events with no root_stack, heatclient falls back to
recursive event fetch
- old heatclient, new server - nested_depth param is never set,
recursive event fetch works as before
Here are some timings for a TripleO overcloud stack with ~700 events.
Current heat and python-heatclient master:
time openstack stack event list --nested-depth 4 overcloud |wc -l
This change, with heatclient 31278ff5f77b152b5ef7a4197e15c441c72ff163:
time openstack stack event list --nested-depth 4 overcloud |wc -l
The difference in event count (744 vs 608) is due to the stack events
being filtered out for stacks with zero resources - these are a source
of unnecessary noise so their removal should be considered an improvement.
In Python3, dict.keys() returns a view object rather than a list. This
behaves differently in that changes to the dict also modify the view, and
in that the view type interacts with various operators in different ways to
One universally correct transformation to preserve Python2 behaviour in
Python3 would be to replace all instances of d.keys() with
list(six.iterkeys(d)), and indeed we did. However, like many automatic
transformations the results are usually unsightly, invariably inefficient,
and frequently absurd. Not least because list(d.keys()) and indeed list(d)
are also equivalent.
This patch changes to using the simplest correct method of accessing the
data we want in each case.
This reverts or rewrites most of commit
Apart from the fact that this method relied on knowledge of the template
format, it also checked nothing useful since we now won't even be able to
create the Parameters object unless all of the parameter definitions are in
There may exist resources that the user (or application) knows are
unhealthy where Heat has no way of determining that.
Add a PATCH handler to the Resource endpoint::
The PATCH method will accept a JSON body of the form::
This patch Implements:
- RPC API to mark resources as CHECK_FAILED in both the legacy and
convergence architectures in heat-engine
- ReST front end to the RPC API call in heat-api
Partially-implements: blueprint mark-unhealthy
The heat-cfn-api wasn't handling the RequestLimitExceeded error.
Instead it returned generic "Internal Server Error". The fix is to
correctly map RequestLimitedExceeded exception in heat-cfn-api.
Added unit test to verify mapping of RequestLimitExceeded error.
The oslo.utils.reflection.get_class_name() handles more variations
of where a class name may come from (on) python 2 and python 3.
Its usage allows getting more accurate class names so we'd better use it.
Adds additional parameter ignore_errors to ignore set
of errors during the template valation in API.
implements blueprint heat-template-validate-improvements
Currently the update preview code has no support for previewing
the effect of an update on nested stacks, which I assume was an
oversight in the original implementation. So this adds a show_nested
flag to the API which allows enabling recursive preview of the whole
update including nested stacks.
Adds an optional list of environment files that can be specified instead
of resolving multiple environments client-side. This change covers both
the REST API changes and the internal RPC API changes.
Implements: blueprint multi-environments
The RPC API call describe_stack_resource is used by two separate ReST API
calls and one CFN API call: Resource.show and Resource.metadata in heat-api
and StackController.describe_stack_resource. The metadata call in
particular throws away all of the results of the describe_stack_resource
output except for the metadata itself. Either this call or the cfn one
(depending on configuration) is also used very, very often: it's the one
that every instance running os-collect-config polls for information about
software deployments (so, to a first approximation, every server in every
stack will be calling this once every 30s).
Since blueprint detailed-resource-show merged in
6d8a5cb35c, every call to the RPC
describe_stack_resource API has resulted in Heat fetching the attribute
values for every single attribute in the resource from its corresponding
OpenStack API (including those calls originating from a request for just
the metadata, or from the cfn API which similarly discards the attribute
This is insanely inefficient (we're making OpenStack API calls to fetch
data that we don't even return to the user). It's quite possibly a
substantial part of the reason why we've had so much difficulty scaling up
Heat to deal with large numbers of servers polling it for config. And it
tends to leave a lot of annoying warnings in the log messages, not just of
Heat but also the other services it is polling, since polling the metadata
generally happens using the heat_stack_user's credentials, not those of the
actual owner of the resource - it can't actually find the resource and
returns a 404.
The fix is to change the default "with_attr" value in the RPC client to
False, and only pass None (the previous default) or a list of extra
attributes to include in the specific case where the ReST API will actually
return the attribute values to the user and not just discard them. Since
the server previously treated any falsey value for the parameter (e.g.
None, False or ) as equivalent, and since nothing was previously passing
False, this change is safe to backport to stable branches. The api and
engine can be updated in any order without change in behaviour until a new
api is talking to a new server (at which point the bug is fixed).
This change also updates the ReST API unit tests to accurately reflect the
data returned from the engine.