Using the healthcheck middleware as a filter is deprecated and
the middleware should be used as an application[1].
[1] 6feaa13610c450c8486f969703768db5319b4846
This change updates definition and usage of the healthcheck middleware
accordingly to avoid the following deprecation warning.
DeprecationWarning: Using function/method 'Healthcheck.factory()' is
deprecated: The healthcheck middleware must now be configured as
an application, not as a filter.
This also refactors composite definitions based on flavor by the new
pipeline factory.
Story: 2009071
Task: 42881
Change-Id: I75386dc4a7dc14b3c753dfff01f147ef8233bf94
change Change-Id: I097bf70431a999a0f6aa56079ffb5743b50d4d7f
inadvertently started to require (keystone) authentication
when accessing API root to get the API version document.
This breaks standard version negotiation (that usually does not require
auth) and also some monitoring / loadbalancing that used to check
returns on GET to API root.
Change-Id: If8f13def196442e6f28616e88972f28f8ec23d0d
Story: 2002531
Task: 22072
Until the context middleware has been processed, logs from any other
middleware will be logged with the request ID of the *previous* request.
Currently this is most logs in the API log files, which makes the request
ID worse than useless for determining what is going on.
To ensure all logs get the correct request ID, move the context middleware
close to the front of the pipeline, right after the request_id middleware
that generates the request ID and the auth middleware (the data from which
is needed to populate the context). Also, explicitly include the request_id
middleware in the cfn-compatibility APIs' pipelines.
Unfortunately, any failures in the auth middleware will still be logged
with the wrong request ID. This appears to be unavoidable, since we can't
create the context until after we have authenticated the request.
Change-Id: I097bf70431a999a0f6aa56079ffb5743b50d4d7f
This patch removes the API, the next set of patches in the
series would remove stack watch service and related
WatchRule implementation.
Change-Id: I8b0472be862907298c8da51f435b5d8b19610ec3
Partial-Bug: #1743707
This patch implements noauth middleware that can be enabled by
adding the following to heat.conf:
[paste_deploy]
flavor = noauth
One use case for this middleware would be to use alongside of a single
process heat-all setup (using fake_rpc, sqlite) to avoid having to
bootstrap keystone to use only the Heat software deployments resources.
We could use this approach to help bootstrap TripleO's undercloud using
heat templates with pre-deployed servers (a single undercloud server
for the intial case).
Change-Id: I50a8cc46b4c3c235d438a711760fba94bf8e9715
This was already used in the API endpoint, but it's also needed in
the CFN endpoint. It's purpose is to process the X-Forwarded-Proto
header (or Proxy protocol if used) and set the protocol as directed
to https if done so. It's only needed if Heat is behind a TLS proxy
(such as HAProxy) and is also disabled by default.
Change-Id: Ibd81e1cf6bc1e3f63728b485e295478afa7f573c
Closes-Bug: #1590608
The default values needed for heat's implementation of cors
middleware have been moved from paste.ini into the configuration
hooks provided by oslo.config. Furthermore, these values have been
added to the default configuration parsing. This ensures
that if a value remains unset in heat.conf, it will be set
to use sane defaults, and that an operator modifying the
configuration file will be presented with a default set of
necessary sane headers.
Change-Id: Ie3791007b33788829417ce508a3c719ae626bbce
Closes-Bug: 1551836
Use oslo_middleware.http_proxy_to_wsgi instead of oslo_middleware.ssl
due to the 'oslo_middleware.ssl' module is deprecated.
Change-Id: Ibb137049ca4005dd9a886de1ecc6b00dbae79789
Closes-Bug: #1526656
CORS middleware's latent configuration feature, new in 3.0.0,
allows adding headers that apply to all valid origins.
This patch adds headers commonly used in openstack to heat's paste
pipeline, so that operators do not have to be aware of additional
configuration magic to ensure that browsers can talk to the API.
For more information:
http://docs.openstack.org/developer/oslo.middleware/cors.html#configuration-for-pastedeploy
Change-Id: Ic32d7d2b8d5e1433f806753e94abdc727db07c68
Starting with opsrofiler 0.3.1 release there is no need to set HMAC_KEYS
and ENABLED arguments in the api-paste.ini file, this can be set in the
heat.conf configuration file.
Change-Id: I77611c08d24839dc01766e994635cdb6a12922da
This adds the CORS support middleware to Heat, allowing a deployer
to optionally configure rules under which a javascript client may
break the single-origin policy and access the API directly.
For heat, the paste.ini method of deploying the middleware was
chosen, because it needs to be able to annotate responses created
by keystonemiddleware. If the middleware were explicitly included
as in the previous patch, keystone would reject the request before
the cross-domain headers could be annotated, resulting in an
error response that was unreadable by the user agent.
OpenStack CrossProject Spec:
http://specs.openstack.org/openstack/openstack-specs/specs/cors-support.html
Oslo_Middleware Docs:
http://docs.openstack.org/developer/oslo.middleware/cors.html
OpenStack Cloud Admin Guide:
http://docs.openstack.org/admin-guide-cloud/cross_project_cors.html docimpact
Change-Id: I185f0d9f85617dd2f482cac4994ccc0a4cb6cf16
We have already moved away from openstack/common/middleware modules
to the oslo_middlware library. Let us cleanup the remaining files
here.
Change-Id: I9fe551385aa11ee0da23d77fc8fef6107ae2a026
The oslo-incubator request_id module has been deprecated and
removed for kilo, replaced by the request_id from oslo.middleware.
Note that we need to leave the oslo-incubator request_id shim in place
until after Kilo ships, so operators get fair warning about the
backwards-incompatible paste.ini change.
Change-Id: Iedbfede6d57312f565cf4b1ccb71a8418fad8620
Partial-Bug: #1380629
This adds builtin rpc and db traces to Heat, as well as
some toplevel stack methods to aid in reading the output.
A 'profiler' config group is added to enable profiling.
Change-Id: Ie5c1c8f1931f59e4d4bcf1ec3b791f55984eb6d2
Closes-bug: #1363782
auth_token middleware in python-keystoneclient is deprecated and has
been moved to the keystonemiddleware repo.
Closes-Bug: #1342274
Change-Id: I1aadbe24db63eb2507b088cd53886d7f2e192cab
This patch aims to support "x-openstack-request-id" for Heat.
Nova, Cinder and Neutron have realized "x-openstack-request-id" functionality
by using oslo-incubator.middleware. This functionality will enable effective
log tracing between Heat and Heat caller.
Change-Id: Ida2f3d33b02557c2117aade27ccac7d9351886c9
Closes-bug: #1324065
This reverts commit e3679217d1.
This commit broke using the heat API when client requests were
behind a proxy (this sets the X-Forwarded-For header)
and effectively causes the heat-api to return the clients
IP address back in the request via the location header.
I believe the original (unapproved) heat blueprint for
this feature should have used X-Forwarded-Host instead.
Closes-bug: #1316754
Change-Id: I1b38ececf59545a3c13c7ebf2c33be97f4332ac0
Adding 'X-Forwarded-For' header support to enable Heat API
proxying
Implements: blueprint proxying-heat-api
Change-Id: I36a0d3dd3f672a485c4a9c0cd541b705033e9025
Refactoring the auth_password middleware to move X-Auth-Url logic
into the auth_url middleware, so that all X-Auth-Url logic is
handled in one place.
This also adds the auth_url middleware in front of the auth_password
middleware, so that there should be no behavior change
Co-Authored-By: Richard Lee <rblee88@gmail.com>
Related-Bug: #1259364
Change-Id: I3819cbf1a4c4955752dc7c804b0add1bab2b962c
authtoken middleware's current purpose is to set X-Auth-Url header to a
value read from heat.conf.
Since this value is not really related to anything the keystone
middleware does and is instead read from a config file, it makes sense
to move it from the authtoken middleware into its own middleware
This change is the first step to grouping all X-Auth-Url related logic
into one single middleware as opposed to have it scattered (or possibly
repeated) in auth_token and auth_password. For example, auth_password
also has some logic around it related to multi-cloud, which can be
extracted and moved to auth_url middleware in a later patch, so that all
handling of X-Auth-Url occurs in one place.
Also, by extracting the X-Auth-Url logic, it allows cloud
providers to remove auth_token or auth_password without side-effects.
Closes-Bug: #1259364
Change-Id: Ieb251c18aa091391a28a90c495b61cf41436f8b9
The Heat API doesn't behave properly if it is behind an SSL termination
proxy. If this is the case, the HTTP redirections and the links
returned in the REST response bodies are build using http protocol
instead of https.
To handle this situation, a new middleware was added. The purpose of the
SSLMiddleware is to update the wsgi.url_scheme environment variable of
the request with the value contained in an HTTP header that can be
configured in heat.conf (by default: 'X-Forwarded-Proto')
Change-Id: I418cd8cf2fb2a5fb3f630b4945084fb6eab57310
Closes-Bug: #1235555
Only refer to heat.conf in the docs and scripts.
For install.sh copy the iniset() function from devstack
to assist in setting some semi-sane defaults.
Change-Id: I933891e35103c003f1272bc89c7b42d2ad76697b
add a wsgi middleware (faultwrap) that catches exceptions
and transform those exceptions into a parsable format
according to 'Content-Type' of the request.
Fixes bug 1158598
Implements blueprint exception-formatting
Change-Id: Iacdb8cc119b250ff1e39c99b7a7f66fd4c35e7d9
This allows waitconditions and cloud watch data to authenticate
using just the ec2token middleware. Stacks have been successfully launched
with a standalone heat onto an external grizzly openstack, including working
waitconditions and watch data.
This means that currently when in standalone mode, heat-cfn cannot
authenticate since it defaults to auth strategy keystone (and it appears
that auth strategy ec2 signing has not been implemented yet). This case
is sufficiently obscure that it most likely won't affect anyone at this
stage.
Implements blueprint heat-standalone
Change-Id: I7d096b11e70c234d0b2322c93bf5f4d4e6b01b4f
Add alternative authentication middleware to authenticate against Keystone using
username and password instead of validating existing auth token. The benefit
being that you no longer require admin/service token to authenticate users.
To use, update heat-api.conf:
[paste_deploy]
flavor = standalone
This should make it possible to try heat out against existing public
clouds.
Change-Id: Ia584bba78e8984581f0fb6882bbb17d5efa238db
Load a single api-paste.ini file, specified by config
Delete unused paste.ini files
Update docs for new paste.ini and config arrangement
There will be a corresponding devstack change, and once this is in
I will email the packagers on the packaging implications
Change-Id: Ic10b1a486094d15bfd832f0f934e6268ec323085
Takashi Kajinami