Now that oslo.context has been bumped to >=2.6.0,
we can use `is_admin_project` from the context which
is backward compatible.
This also adds a new rule `project_admin` to make
resource types accessible inline with current policy
of other services like nova, that are yet to use the
`is_admin_project` feature. Once those services start
using the is_admin_project feature, we can remove this.
Change-Id: I5be8176042f8839e86f77984222e7fac66dfaed6
Related-Bug: #1466694
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.
APIImpact
Implements: blueprint files-show
Change-Id: I3198b6a7dc06648af24c198d39470f3b0d5d6f11
Change namespace of some files to '*aodh*' instead of '*ceilometer*'.
Blueprint migrate-to-use-aodh-for-alarms
Change-Id: I2c4d565ded5f9f7146b23479acd2702f976b8833
The combination alarm is deprecated and disabled
by default in Aodh, and will removed after two release
cycles in Aodh. Keep the same with Aodh, this change
deprecates combination alarm resource, before hidden it
we use ceilometer client as before because aodh client doesn't
support to manage combination alarm.
Blueprint migrate-to-use-aodh-for-alarms
Change-Id: Ibe8fe35a0cf9efe3d2809041ee480c99a75166cd
This changes:
1. use aodhclient to manage gnocchi alarm
resources, including create, update, delete, check, suspend,
resume and show.
2. rename OS::Ceilometer::Gnocchi* to OS::Aodh::Gnochhi*
3. considering to compatible with old templates with gnocchi
alarm resources, set resource_registry to map Ceilometer gnocchi
alarms to Aodh gnocchi alarms.
Blueprint migrate-to-use-aodh-for-alarms
Change-Id: I1507e5c82dbd7437000900eb1a46fe37806833b1
This changes:
1. use aodhclient to manage OS::Ceilometer::Alarm
resource, including create, update, delete, check, suspend,
resume and show.
2. rename OS::Ceilometer::Alarm to OS::Aodh::Alarm
3. considering to compatible with old templates with resource
OS::Ceilometer::Alarm, set resource_registry to map Ceilometer alarm
to Aodh alarm
Blueprint migrate-to-use-aodh-for-alarms
Change-Id: I6e2d14f15a345b927b53adc237cf2bf4010842f0
The changes including:
1. Avoid hard code of resource and output keys
2. Decouple hot and cfn for outputs
Change-Id: I1fd7e08ff5c699ddfcf98c81aed5f0d91c4248b3
This allows admin super user (user with admin role in admin_project)
to do stack operations across all projects.
Change-Id: Ifbf56fde02b89248ee788e6a212ef9d11e665dc0
Partial-Bug: #1466694
Adds default policy rule for resources which are limited to
administrator, to forbid non-admin to create these resources
at the very start.
Change-Id: I9e1ef86f0c44bce5bde3f9e26e1f2b9cb3aef06d
Closes-Bug: #1582187
Adds a call to the REST API to retrieve the environment for a running
stack.
APIImpact
Implements: blueprint environment-show
Change-Id: I7e3577dfc854018245d79afdfee45a9d250d73a7
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
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::
/stacks/<stack_name>/<stack_id>/resources/<resource_id>
The PATCH method will accept a JSON body of the form::
{
'mark_unhealthy': <bool>,
'resource_status_reason': <string>
}
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
Change-Id: Ifa48b179723a2100fff548467db9e162bc669d13
Partially-implements: blueprint mark-unhealthy
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
APIImpact
Add new APIs for showing and listing stack outputs.
It can be used by heat client and separately for
getting stack outputs.
implements bp api-call-output
Change-Id: Ia24b24f59e2c592801e4e670ba5510f642ecf45c
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
Currently attempting to do a preview update call with PATCH fails,
because we didn't align the behavior of preview update with the
actual update in the recent additions to fix bug #1224828
So, refactor to ensure both preview_update & update use the same
code, and add a PATCH path to the update API.
Change-Id: I8ce5c0ea4035a7b9563db10ea10433e7f5f99a4f
Closes-Bug: #1501207
(cherry picked from commit 604595a39c)
Currently attempting to do a preview update call with PATCH fails,
because we didn't align the behavior of preview update with the
actual update in the recent additions to fix bug #1224828
So, refactor to ensure both preview_update & update use the same
code, and add a PATCH path to the update API.
Change-Id: I8ce5c0ea4035a7b9563db10ea10433e7f5f99a4f
Closes-Bug: #1501207
Allow users to see what resources will be changed during a stack-update.
Docs change here https://review.openstack.org/132870/
Client change here https://review.openstack.org/#/c/126957/
BP: update-dry-run
Co-Authored-By: Jason Dunsmore <jasondunsmore@gmail.com>
Change-Id: If58bdcccfef6f5d36c0367c5267f95014232015e
Heat's `policy.json` now can contain policies of the following schema:
"resource_types:<resource_type>": "rule"
This will allow cloud admins to control resource access utilizing
user roles, names, tenants and any other oslo.policy-supported rules.
Basic usage is to facilitate fail-early for stacks with resources
that a given user will not be able to actually create
due to role restrictions.
Default policy is 'allow to everyone' (who has passed previous policy
checks on REST API layer).
Resource types that the user will not be able to use due to
resources policy restrictions are hidden from `resource-type-list`.
Current operations that are prohibited if the user
does not pass policy check for a particular "forbidden" resource:
- show resource type for forbidden resource type
- show resource template for forbidden resource type
- create a stack containing a forbidden resource
- delete a stack containing a forbidden resource
- update a stack that already has a forbidden resource
- update a stack initroducing a new forbidden resource
- restore a stack snapshot to a stack that currently has forbidden
resource
Not yet prohibited, need to be fixed:
- restore a stack snapshot that will create a forbidden resource
As first step (and for testing purposes) OS::Nova::Flavor is forbidden
to create for non-admin users. Simple functional test using this
resource is added.
Change-Id: I337306c4f1624552a2631e0ffbb43f0d3102813d
Implements blueprint conditional-resource-exposure
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
Adds required REST API, Db model and engine service
changes for reporting the heat engine service status.
Change-Id: I3ef29c1efd2015d62eec1033ed3a8c9f42e7a6e2
Implements: blueprint heat-manage-service-list
"DocImpact"
This file keeps breaking our gate, because libraries we depend on
release and the generated content changes.
The check has been disabled, but to avoid the sample config becoming
totally stale, remove it and replace with a README which says
how to generate the current sample config.
Change-Id: I1c43e5cf2a7ab6fa388b91fd420392996c368e72
Relying on [1], property Dimensions isn't required, but
this template has no Default value for Dimensions
(thereby making it required). This patch fix that omission.
Besides that, parameters have wrong parsing, because if
parameter with type 'CommaDelimitedList' has default
value '', parameter's parsing result would be [u''] instead
of []. this is wrong, so this patch fix it.
[1] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-alarm.html
Change-Id: I259249659c8b5dc846432f8e08985b148b30d682
Closes-bug: #1386824
oslo.db just released a new version, and it's broken our gate config
check, so update it.
Change-Id: I0d077d0f55fbc2ab9faac5ff9deaadba00452869
Closes-Bug: #1393559
This adds the external HTTP API and the RPC methods to invoke stack
restore.
blueprint stack-snapshot
Co-Authored-By: ala.rezmerita@cloudwatt.com
Change-Id: Id1ec0c11c9f12c23b3eec12a853db6ee4ff90277
This change enables clients that have no specific settings in
the [clients_xxx] sections of the configuration file to get defaults
from the [clients] section.
Change-Id: I071bd77a2e1f0ad366b80c095917a8debc5cef2b
Closes-Bug: 1379958
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
Sync 838a2a3 oslo-incubator to get the new request_id shim, so
can introduce a deprecation warning that tells operators upgrading
from Juno that their paste.ini files need to point to oslo.middleware
This also syncs all other modules, except policy, which looks like it
needs some changes to heat thus will be handled via another patch.
Note we shouldn't remove this request_id shim until after Kilo is
branched.
Change-Id: I35125ffa263b0522ff6dd0b80b0beb3cbc79999b
Related-Bug: #1380629
This change the default value of the option
'trusts_delegated_roles' to []. And delegate all of
the trustor roles when create the trust unless
user set the option to subset roles.
Change-Id: I3f1b70b78b91bfac9af5fadb71140679b208c999
Closes-bug: #1376562
There's references to the auth_token middleware in keystoncelient.
The auth_token middleware has been moved to keystonemiddleware and
the version in keystoneclient shouldn't be used anymore.
If these references aren't updated, then when options are changed in
keystonemiddleware.auth_token the heat-api will fail to start because
there's duplicate options in keystoneclient.middleware.auth_token.
Change-Id: I04573aa5ff967afe3e00329f797fcc71b779e7b3
Closes-Bug: #1379082
There's references to the auth_token middleware in keystoncelient.
The auth_token middleware has been moved to keystonemiddleware and
the version in keystoneclient shouldn't be used anymore.
If these references aren't updated, then when options are changed in
keystonemiddleware.auth_token the heat-api will fail to start because
there's duplicate options in keystoneclient.middleware.auth_token.
Change-Id: I04573aa5ff967afe3e00329f797fcc71b779e7b3
Closes-Bug: #1379082
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
This also adds a deprecation warning.
This also changes the default to use Ceilometer.
Release message:
Anyone deploying Heat should not be using OS::Heat::CWLiteAlarm, but
OS::Ceilometer::Alarm.
CWLiteAlarm should be explictly disabled in /etc/heat/heat.conf by
setting "enable_cloud_watch_lite=false". This will stop Heat from
running a period task check for alarms.
DocImpact
Change-Id: I2a10c14772bdafc001e211d7e94502ac1f6b32b1
Closes-bug: #1322128
For stack-update, add a new PATCH ReST API and a new CLI
argument named existing-parameters to indicate that the set
of parameters should be patched over the existing parameter
from the DB. A new method in environment handles
the patching.
Partially-implements: blueprint troubleshooting-low-level-control
Partial-Bug: 1224828
Change-Id: I802e0dca44926be3a3f45fcaa995c866a4abf998
Update requirements for oslo.messaging 1.4 and regenerate config file,
where redis options has been fixed again. It will unblock the global
requirement sync job.
Related-Bug: #1332588
Change-Id: I0d1dc758504e76131738614ccd429171b7c40df1
This change does the following:
- reverts commit 04de60093b
- reimplements Resource.is_using_neutron to check for neutron by
attempting to create a neutron client
- fix mocking in tests for changes which landed after 04de600
If there is no 'network' entry in the service catalog then
keystoneclient will raise an EndpointNotFound. The context will
already have a keystone client cached which has a full service catalog
locally, so calling is_using_neutron should have no particular overhead.
This fixes a tripleo regression where the autodetection is triggered
before keystone is ready, so that heat-engine fails to start. This
race does not affect devstack as keystone is fully configured before
heat services are started.
Not adding config option networking_service will also prevent
extra work required by downstream installation tools.
Change-Id: I45a6154fa560f672d8d1942bf57f39601110bfc6
Closes-Bug: #1362812
Adds a heat.conf option to set the OpenStack component responsible for
networking, and makes heat-engine auto-discover the networking service
on start up if such option is not set.
Also adds a convenience method to Resource class to let resources decide
what networking service to use.
Implements blueprint discover-networking-service
Change-Id: If7121089068cc2d2774bedb73e4e252b520eb5b3
auth_token middleware in python-keystoneclient is deprecated and has
been moved to the keystonemiddleware repo.
Closes-Bug: #1342274
Change-Id: I1aadbe24db63eb2507b088cd53886d7f2e192cab