This change supports:
1. Allow boolean value or condition function as
condition name of 'if' function:
resources:
r1:
...
properties:
a: {if: [true, 'value_true', 'value_false']}
r2:
...
properties:
b: {if: [{equals: [...]}, 'value_true', 'value_false']}
2. Allow boolean value or condition function as
condtiion name in resource definition:
resources:
r1:
...
condition: false
r2:
...
condition: {and: [cd1, cd2]}
3. Allow boolean value or condition function as
condition name in outputs:
outputs:
output1:
value: ...
condition: true
output2:
value: ...
condition: {not: cd3}
Change-Id: I2bf9bb0b608788c928d12425cbfdaf658df9e880
Co-Authored-By: Zane Bitter <zbitter@redhat.com>
Blueprint: support-conditions-function
Current plugin-guide page is obsolete and needed in
updating. This patch adds all necessary info to page.
Change-Id: I72f81cc9e1d48458f677c4056da69ed79bb71fd9
This reverts commit 4a8ad39a3881c0743916f016b4763015946f127d.
There was no protection against circular references causing infinite
recursion.
Change-Id: I35226420c458474e75716591d587e73a82e75688
Closes-Bug: #1621529
This change allows reference with other conditions by name in
definition of a condition, something like:
conditions:
cd1: {equals: [{get_param: env_type}, 'prod']}
cd2: {not: cd1}
cd3: {equals: [{get_param: zone}, 'fujian']}
cd4: {and: [cd1, cd3]}
Change-Id: I4fbc3839977d2d4299d65d4d56e3d41d56d07aef
Blueprint: support-conditions-function
If you attempt to update a stack containing
OS::Heat::SoftwareDeployments resources, so it uses the new
non-deprecated OS::Heat::SoftwareDeploymentGroup type instead, it
deletes the group, and all of the deployments.
This means that any deployment "actions" property will be
misinterpreted, e.g if you have actions: CREATE, all the deployments
will re-run on the update, even though it's an update, not a create.
This issue exists on all deprecated resoruces, when we trying to upgrade
to new version of it by update.
This patch fix above update issue by check if resoruce was deprecated
and been update by replacing resource (which is the parent class of
existing resource).
Change-Id: Ib7880120a90c4497a7ceea53eee55c220a28d14e
Closes-Bug: #1528958
Currently we are using the new address for api reference. But
heat/doc/source/index.rst still uses the old one.
Change-Id: Ie1423e01a39b1f24fd3fa12368abcb87c8b1ac7c
Support 'not' and 'Fn::Not' for templates:
AWSTemplateFormatVersion.2010-09-09
heat_template_version.2016-10-14
Change-Id: I6a9c89a23160a2cf06c37677871bcfbfab9599be
Blueprint: support-conditions-function
Provides output condition for cfn/hot templates,
if the condition of output evaluates to false, will
set output value to None.
Change-Id: I0398e39541a4176ef5699331c10536c59f1cb3e7
Blueprint: support-conditions-function
This adds support for the following to the template:
heat_template_version: 2016-10-14
resources:
...
res_a:
type: OS::Nova::Server
external_id: the-new-server-id
properties:
...
Co-Authored-By: Rico Lin <rico.l@inwinstack.com>
blueprint external-resources
Change-Id: I8fda1380504d1d8b1e96649bf20b86d6309fdeca
Nova expects scheduler_hints to be a DictOfListOfStrings in
the object layer(versioned objects), though there is no
limitation for this in the api layer. Thefore sending a
list of tuples as a scheduler_hint results in error.
This also sets stack_scheduler_hints=true for integration
tests.
Change-Id: Id7575f67657fab86acb22d86807127dda45305d5
Closes-Bug: #1608452
This changes:
1. Support 'Conditions' for AWSTemplateFormatVersion: 2010-09-09
2. Support 'conditions' for heat_template_version: 2016-10-14
3. There is no need to add a new HeatTemplateFormatVersion template,
because we decide to support conditions in AWSTemplateFormatVersion
and heat_template_version: 2016-10-14, so remove the
HeatTemplateFormatVersion.2016-10-14
4. Move the definition of function 'equals' to hot/functions.py
5. Mark 'equals' as condition function which supported in conditions.
Change-Id: I2e7bdfa1c2052e75f35f2bd0003cdc170188d8b8
Blueprint: support-conditions-function
While testing I discovered a couple of corner cases not previously
handled:
- If you provide values/keys via a get_attr reference it's possible for
them to be None during validation
- If the input map has an unhashable value, it breaks the values replacement
so we need to tolerate a failure to lookup an unhashable key in the values
data.
Change-Id: I14d92056e0a07816a216aba752711887e8ac0aa5
Add project-id argument to heat-manage purge_deleted command in order
to be able to hard delete DB entries for a specific project.
Change-Id: Ifffe5657a40ce97db9d059ff1516b8e1eb801132
Implements: bp heat-manage-purge-deleted-tenant
I missed adding the reno in https://review.openstack.org/#/c/343731/
and there was a minor docs nit mentiond also.
Change-Id: Ib78ca19b96a239c0a06758c259e2e74e10ed26e5
This adds a new map_replace function that can iterate over a map
(e.g json parameter) doing key/value replacements.
Change-Id: I29f0e438c398fda715c79727ed5de8383e5b5d7b
Implements-Blueprint: blueprint map-replace-function
Change namespace of some files to '*aodh*' instead of '*ceilometer*'.
Blueprint migrate-to-use-aodh-for-alarms
Change-Id: I2c4d565ded5f9f7146b23479acd2702f976b8833
Current Support Status guide omits information about
Resolve rule in translation mechanism, so need to add
it.
Change-Id: I2ad9765bb1c68582c75049d37311e50167a0ada7
Closes-bug: #1597226
Release version names are easier for template authors to remember than
seemingly arbitrary dates. It should also make it clearer to new Heat
users that heat_template_version is not like a BIND zone file version
(which would be incremented with each version of the template).
Change-Id: Iae9b6a676702b2a115b18fdfb1ab2afbe5faacde
blueprint support-alias-for-heat-template-version-names
These moved, so update the index, and align it with the parent index
page referencing developing guides content.
Change-Id: I3ffe44b112e0c6f65bb8dcdab064bf6d0879a46a
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
lists.
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
4ace95ad47da7099191a06325c5d0b156fd54894.
Change-Id: Iba3cf48246d8cbc958d8fb577cd700a218b0bebf
