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 14 of a serie of 28 patches
Change-Id: Iccb743056c631f2e0728013942d764cd8b1ecfe0
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
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
Remove useless part of TranslationRule. Now, only Translation
class implements translation mechanism.
Change-Id: I303cb935d8750557274d5d97d8ef9a66ccf657ed
Closes-bug: #1620859
Disable old translation mechanism and enable new
one. Integrate it with Properties class and correct
tests.
Change-Id: I953a52e9b165d3ea4fb2fc57ceea8083c7f8f30c
Closes-bug: #1620859
Add method translate to Translation - the main part of mechanism.
It allows to translate properties values by rules and store resolved
translation, if corresponding flag is enabled.
"Delete" rule added for deleting existing properties values.
Change-Id: I87a02bd3dbf349de9f0f2b3d5439e5ddab89caae
Closes-bug: #1620859
Implement base rules storing in Translation mechanism,
which will translate some property iff it called.
Rule's value_path/value_name resolved to value and saved to
rule's value. Each property could have several translation
rules for it.
Change-Id: Ia08895bba85d4b217075ad21836ea725eccb44d6
Closes-bug: #1620859
Currently if translation data is function and translation path
runs over unresolved function's value (i.e. intermediate data is
function), translation works incorrectly and raises AttributeError.
This workaround makes translation skip rules, where translation values
contains inside functions.
NOTE: This patch is not solve issues, described by Zane Bitter in [1],
just add workaround for current mechanism. Also, it doesn't affect
destination values, just intermediate, which currently cannot be safely
resolved.
[1] https://bugs.launchpad.net/heat/+bug/1620859
Change-Id: I5d7f8d3a615590325d38702b21f224ff3de33315
Closes-bug: #1630214
As functions can be inside other functions, there is no
point in checking for specific functions that can be
template specific. Better to resolve all before
translating.
This also adds a functional test to avoid breaking this
in the future.
Change-Id: I5f72f7455384b3fd5650bd01e77e64bf485dd178
Partial-Bug: #1620859
1. Currently translation rule raises property conflict exception,
if there's some conflict. Error doesn't contain path, where it
has been raised, so need to handle this case.
2. If properties data has list of dicts, from which some key should
be deleted, delete rule raises KeyError if there's no key. Need to
handle that case.
Change-Id: I77b1ed72db51a5bd292fb1ccbe5a06f5f06a5a8c
HOT is our canonical native format, so define the cfn intrinsic functions
in terms of the HOT functions instead of the other way around. Ensure each
function has a consistently-formatted docstring appropriate to its template
type.
Change-Id: I743446bdef3fd7472537db75bf9e0fbfb164e36a
This reverts commit 36bf170f34.
The construction and validation phases of intrinsic functions are
deliberately separated, to:
- Reduce the amount of unnecessary work done
- Reduce the risk of changes to validation breaking the loading of existing
stacks from the database
- Ensure that the most critical errors are reported to the user first
This patch reverts a commit that sought to combine the two phases. There
was no linked bug and no explanation other than that this 'improved'
things.
It does not, however, restore the check for the Removed function during
properties translation (and the associated test), because I believe its
original existence was based on a misconception. There is no way in
practice for a hot.functions.Removed object to appear in the properties a
translation rule is operating on.
Change-Id: I59d02e540771baf4fe078081cd0993a3251eb9a6
Improve translation mechanism: now
during creation of a translation rule there's the
ability to specify custom path for value. It will
be used for map-type properties without inner schema.
Change-Id: I49ade1dd05f2ac484089d34a2ce21e8f5beaf3ae
Closes-bug: #1544172
Move validation code to __init__ method for these list of
functions: Removed, Repeat, Yaql, so now validation error will
be found during template.parse() and returned with a path
to the function in template. Don't change validation for
GetAttr, because it resolves some arguments and we need to parse
template before we can use resolve().
Also, remove check for Removed function in translation, because
now we can't have Removed in properties.
Change-Id: I4f2e1ebee37e82badcdca9110cadc649aa01be8c
Improve translation for list-type properties
in subschemas of list-type properties.
Change-Id: I4d877c146988f54599614d4e69da9330ffa70afd
Closes-bug: #1551859
Rename source_path to translation_path in translation,
which clarifies, that the path means where we should do
changes.
Change-Id: I8ffc157dee95e9f5507773b3cf4969cf9a2a289b
Don't execute translation rule for property that contains
a GetParam function that can't be resolved at the moment.
Such situation happens when we try to resolve get_param function
that refer to parameter with None value. We receive parameter value
from parent stack, where this value is a reference to some resource
without resource_id, so this situation is legal for stack preview
and we shouldn't fail. Note, that we can reproduce this behaviour
only with resources with hidden parameters and overrided get_resource_id
method, that returns None if resoruce creation has not been started yet.
Change-Id: Ia1097940db983721c8b5116db7ee0a2c4c45339d
Closes-Bug: #1548802
We can completely remove 'RESOLVE' translations involving client
lookups in resource init. As we are doing translation before create
and update, it seems we can avoid it.
However, we would need other translations, like 'REPLACE' for property
vaidations(ex. required properties that would be replaced by deprecated
properties). This would be done only when strict_validate=True to avoid
this with template-validate.
Change-Id: Ie80bdd10726a8fc8a8787b78db93acffd333137f
Closes-Bug: #1554927
Partial-Bug: #1554380
Adds a new `Resolve` rule to resolve property using specified
client plugin and finder.
Also refactors the execute_rule function to split out the
rule specific logic.
Subsequent patches in the series adds usage of this rule for name_id
properties.
Change-Id: If598597d0fe92ccba1c0823f36388838c549ba88
Partial-Bug: #1514680