The abstract base classes previously defined in 'collections' were moved
to 'collections.abc' in 3.3. The aliases will be removed in 3.10.
Preempt this change now with a simple find-replace:
$ ag -l 'collections.($TYPES)' | \
xargs sed -i 's/\(collections\)\.\($TYPES\)/\1.abc.\2/g'
Where $TYPES is the list of moved ABCs from [1].
[1] https://docs.python.org/3/library/collections.abc.html
Change-Id: Ia282479bb1d466bd2189ebb21b51d91e89b9581e
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This change allows a Macro returns a 'null' value (as opposed to None)
that makes it effectively cease to exist when that makes sense. If it
appears as a list item, that list item is dropped. If it appears as a
value in a dict, the corresponding key is removed from the dict. If it
appears as a property value, the property is treated as if the user had
not mentioned it in the template.
In all other circumstances (as an argument to a Function, as the top
level of some other field, like an output value), the result will still
appear as None.
A null value is represented internally by the Ellipsis singleton (to
distinguish it from None, which is a value that may appear in the
template from a user or be returned from a Function).
Change-Id: Iaed0982e0db902f6eaf8f986c12b4885bd77e8b9
Story: 2007388
Task: 38976
Properties._get_property_value() is hard to follow and contains
duplicated logic. It also duplicates some logic with get_user_value().
This patch refactors the shared code into a new _resolve_user_value()
method, and replaces the previous elif tree with more sequential ifs.
This allows us to make a decision in _resolve_user_value() about whether
there is a user-supplied value we should use, rather than the decision
being made based on simple inspection of the data dict at the start.
Change-Id: Id8a5f4c7a6103d6cdb2e46bb3b489909e71e85c2
Story: 2007388
Six is in use to help us to keep support for python 2.7.
Since the ussuri cycle we decide to remove the python 2.7
support so we can go ahead and also remove six usage from
the python code.
Review process and help
-----------------------
Removing six introduce a lot of changes and an huge amount of modified files
To simplify reviews we decided to split changes into several patches to avoid
painful reviews and avoid mistakes.
To review this patch you can use the six documentation [1] to obtain help and
understand choices.
Additional informations
-----------------------
Changes related to 'six.b(data)' [2]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
six.b [2] encode the given datas in latin-1 in python3 so I did the same
things in this patch.
Latin-1 is equal to iso-8859-1 [3].
This encoding is the default encoding [4] of certain descriptive HTTP
headers.
I suggest to keep latin-1 for the moment and to move to another encoding
in a follow-up patch if needed to move to most powerful encoding (utf8).
HTML4 support utf8 charset and utf8 is the default charset for HTML5 [5].
Note that this commit message is autogenerated and not necesserly contains
changes related to 'six.b'
[1] https://six.readthedocs.io/
[2] https://six.readthedocs.io/#six.b
[3] https://docs.python.org/3/library/codecs.html#standard-encodings
[4] https://www.w3schools.com/charsets/ref_html_8859.asp
[5] https://www.w3schools.com/html/html_charset.asp
Patch 6 of a serie of 28 patches
Change-Id: Ic56cf6da5ff9ab8f4bd218e6516b87f47165206d
We allow users to provide a description for a resource that shows up in
the Heat API. Many resource types also allow users to add descriptions,
and these have typically been exposed as properties rather than by
trying to read the resource's own description.
To prevent the need to duplicate information, use the resource's
description as the default for any top-level properties named
'description'.
One downside of this is that any changes to the resource description
could cause updates to the resource. (However, there are no issues
specific to updgrades, because the subsitution is also done on the
previous properties.) To guard against the worst of this, only enable
this behaviour if the description can be updated without resource
replacement.
Change-Id: I56560d014a02b5f2ddbc08689d39147fbe4ffca4
When translating name to id, if we don't find the resource it's
better to ignore the error and return the non-translated value
for before properties.
Change-Id: Ic25c35098cff8b68e184a336b21f2e8df70bb1ee
Story: #2003015
Task: 23103
When a property value does not match the defined type of the property, we
include the offending value in the error message for all property types
except 'string'. This brings string properties into line with the other
types, for easier debugging.
Change-Id: I34ac7bad414403707f2e8a8f2dfbf804fa9bfaa7
Related-Bug: #1742646
This reverts the commits f5c32ad8fd and
14fdf72b000c82a80abb2587189dd7c6c7dfa0a0e.
The constraint never worked and the stuff to pass the template to
constraints (which was broken because we actually passed a
ResourceDefinition instead) is a pain. Just get rid of it rather than
fix it.
Change-Id: I4e1e787ad94ac1951f472ea066a9b1c9d3e03611
Closes-Bug: #1661403
In the recent refactoring done in
I953a52e9b165d3ea4fb2fc57ceea8083c7f8f30c, we didn't handle translated
require properties correctly, forgetting to raise an error when the
property was required. This fixes that path.
Change-Id: If335ca193301d304963738773d10e7370d5b5d85
Closes-Bug: #1685808
Disable old translation mechanism and enable new
one. Integrate it with Properties class and correct
tests.
Change-Id: I953a52e9b165d3ea4fb2fc57ceea8083c7f8f30c
Closes-bug: #1620859
Add full path field for Property class. Now
properties with sub-schemas should contain properties
with path, where their parent specified. For example,
if there is schema:
"a": type map:
schema:
"b": type string,
"c": type string
Then property "a" has path == 'a', "b" has path == 'a.b',
"c" has path == 'a.c'.
Change-Id: I6d0ba022f34b925d47142669d6076ebd63a2acdc
Related-bug: #1620859
Currently Properties has arg "parent_name", which
is used for detailed path in error and allows to
build path for nested properties schemas. But on
top parent_name takes resource name as initial,
which is few incorrect - Properties should raises
with error about Properties, other info (about in
what resource this error raised) should be built out of
Properties module.
Change-Id: I36e6453a1589c02a3f8cf2c080b38693b23b0f1b
Related-bug: #1620859
Use allow_conversion flag to convert comma_delimited_list
to list before validation when using from_parameter.
Change-Id: Id144aade23eee13df227acdb728906c8dd345337
Closes-Bug: #1617019
The OS::Heat::Value resource provides a "value" attribute that may be
calculated through references to other parameters or resources. Other
resources may then reference this value.
The primary motivation is to avoid having to create nested templates
that only exist to execute these kinds of data transformations.
This resource's "type" property is optional but recommended.
Change-Id: I72fdab8261336644a9545668fac6f4e49a785e36
This doesn't check any user input, but checks the validity of the
schema itself, so better to do it during schema validation.
Note, that now heat engine doesn't start in the case of invalid schema.
Change-Id: Iec5ca304eae780f8c028f7eb59cc7ee8710043a1
The validate method for a constraint only accepts the value being
verified. This is sufficient for most data checks (range, regex) and the
calls to one of the service clients. But it is limiting in the sense
that it prevents us from ever having constraints that span multiple
parameters (such as ensuring that two values are compatible).
What caused this is the atttempt to add a constraint to ensure a
parameter's value is a valid Heat resource type. To verify this, the
constraint code needs access to the resolved environment. I opted to
pass the entire template down instead to make things more flexible.
The call to the BaseCustomConstraint (which appears to be the entry
point for most plugins) will attempt to use the new signature with the
template, but will fall back to the original call for backward
compatibility.
Change-Id: I5dc94c964b35578e84da641278a4175a37038498
When creating a properties schema for a TemplateResource, we should not
include the default parameter values specified in the template because
properties lack the type conversions that parameters do (specifically, a
comma_delimited_list parameter converts a string value to a list using
str.split()). We don't even pass defaults to the nested template anyway,
because it is the parameter parsing in the child stack that handles
substituting in any defaults.
Change-Id: Ic7251cf0fcb77cc2acae43dc3c1d9f4671e4a52e
Closes-Bug: #1564106
Add a new "immutable" boolean field to the parameters section in a HOT
template. A value of True will result in the engine rejecting
stack-updates that include changes to that parameter. When not
specified in the template, "immutable" defaults to False to ensure
backwards compatibility with old templates.
blueprint: immutable-parameters
Change-Id: If17df0b97e96ff2a1926451634e4744d6c3e26f1
The constraints generated by the resource-type-template command are
improperly formatted for parameters, resulting in an invalid template
being created. This fixes the parameter generation code to make sure
the constraints are properly formatted.
Change-Id: Ifa0d63d30ff0a3b3fea5476e10982585b42597d6
Closes-Bug: #1545832
The process of bringing us into compliance with the H405 pep8 rule has left
us with a lot of docstrings that either don't follow the recommendations of
PEP0257, are misleading, wrong, or nonsensical. This patch attempts to fix
them up.
Change-Id: Icfe90b5ba3102a7e13ab659038a8b2af9019e9e6
If some map or list type properties specified with
json-type or commadelimitedlist parameters, error
raised in case of wrong properties data parsing.
Fix this case by adding check if data is GetParam
instance, resolve it. Other function can be safely
replaced without resolve.
Change-Id: I0c9a6af29b56b629cbdad2acb868c3033e38b5ef
Closes-bug: #1494364
The child_params calculation doesn't differentiate parameters
provided via the properties vs those provided via the template
defaults (defined in the nested stack template), which leads to
confusing results when you look at the parameters for the nested
stack, as the defaults are exposed as parameters passed in
to the stack, when the parent didn't pass anything via properties.
Closes-Bug: #1498107
Change-Id: Ic58cdcd15db09cd8d8d3d52fadfb68aa5709e7d8
If json paramter `default` of nested stack is set to
[], it resets it to {} and nested resource validations
fail. This patch fixes it by allowing empty list to
passthrough.
Change-Id: I153e9a94566679c01d6ca21713233e3140769ded
Closes-Bug: #1486778
If TranslationRule defined with REPLACE rule and value
defined with value_path, delete value_path property data
after replacing.
bp deprecating-improvements
Change-Id: I314ff90a10c86a11964200ca46187966507f32ef
Add specify translate_properties for Resource to
overload for every Resource with old and new properties.
bp deprecating-improvements
Change-Id: Ifd81eac3cd4496c1efdf8fdaa4c28cb02478ba46
This doesn't change behaviour - it was implicitly returning None before -
but it makes the code a lot easier to read because it is now clear that we
can return None if the property is not required, does not have a default,
and is not specified by the user.
Change-Id: I7b4a177fde0b3acf7ea55a44e9fc60e716c0f7b1
Should do constraint validation for None value property
when validate if the property has no dependency of any other
Init resource.
Change-Id: Ie22d01de517f25b1f160c84c8c94b8950e528399
Closes-Bug: #1444898
Currently heat supports to create CFN template based on
the given resource type. And this patch adds an option
to allow user to specify template type to generate(support
HOT template at the same time).
blueprint support-to-generate-hot-templates
Change-Id: I55cfb9b0f87e638350f2f6367fb399d772fff7e1
In some cases, there is no information about resource and
section, where Property error raised. This patch improves
StackValidationFailed msg, so this msg look like "Property
error : resource_name.section_name.key_name: error_msg", where
section_name is section, where Property error raised, e.g.
'update_policy'.
Change-Id: Iab2a6acdec254b39983de420ab03f994cff48d89
Closes-bug: #1358512
Currently we have a somewhat bogus internal equivalence between the
"json" parameter type and the MAP property type. This is a problem
when exposing json parameters via provider resources, because the
schema of the exposed property does not exactly match the capabilities
of the underlying parameter.
Specifically, json parameters can take strings (json serialized list or
map), and also lists and maps directly. Currently, we can only pass
maps, which means some data, for example a list of maps (which is possible
when interacting directly with a json parameter) is not possible when
using the same parameter abstracted via a TemplateResource.
To work around this add a flag which relaxes the type rules and enables
some coercion of map values, only when they're going via a schema derived
from a json parameter.
Change-Id: I8eff36c4343a07b644b84aa9f2f74eceeb62b4a9
Closes-Bug: #1420196
Improve docstrings so that syntax warnings are no longer displayed when
generating docs.
Related-Bug: 1403897
Change-Id: I0163bc7f83e00f9077fc78e638173df2124580dd
For python3 compatible, using six.string_types instead of
basestring(). six.string_types represent basestring in
python2 and str in python3.
Change-Id: Ib4ba3d164f782601944023b99d6cc1ee2763ee85
Since i18n.install() is deprecated, remove it from heat codes and
import i18n._() to where it needed.
blueprint oslo-i18n
Change-Id: Icefada18b5a33112b425cd90d31d3a6a5f06188a
Instead of rising an exception, boolean and integer values are
converted into string if string is expected.
Change-Id: I1e0014576c4df447bfa1595c530f1e24f411195d
Closes-Bug: #1367375
If a developer defines a default boolean as "true", then we really want
True when we do "self.properties['bla']" not 'true', otherwise this
is not consistent.
Change-Id: I3705e573e2fd68a04b26c5589d38f84d68641738
Partial-bug: #1375151
Using references on resources defined in template may be cause
of error during validation. This fix checks reference on another
resource and skips validation if resource is in INIT state.
Change-Id: I95531a1603de1e8c4b9f0f4b05b62eebc48beb3c
Co-Authored-By: Zane Bitter <zbitter@redhat.com>
Closes-Bug: #1347571
Closes-Bug: #1339942
The type of template Resource property schema converted from parameter
is the same as input parameter type, including Number/String/Map/List.
Resource property schema type includes
Integer/String/Number/Boolean/Map/List. The Integer type is converted
from Number type, while Boolean type from String type.
Change-Id: Ic8ba281b5fb6e17a25fb8b5ba6a1102c827e42b9
Closes-Bug:#1317129
Currently resources support only in-place update or (default)
UpdateReplace. In order to support AWS "Updates are not supported"
feature, this new property attribute is added, with default value False.
It is going to be used for denying an UpdateReplace
behavior of the resource (similar to update_allowed currently).
Change-Id: Ie94241630d9595b58ff6b84bcb94459b0785fc03
Implements: blueprint implement-aws-updates-not-supported
According to https://wiki.openstack.org/wiki/Python3 dict.iteritems()
should be replaced with six.iteritems(dict).
Change-Id: I9e2881a006433c8b44a3caccebc73bae4973a041