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>
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 13 of a serie of 28 patches
Change-Id: I09aa3b7ddd93087c3f92c76c893c609cb9473842
Raise a proper error when something wrong is passed in a depends_on
field.
Change-Id: I9d27cc48a7f4c050fcc89ab5d07b19329d228955
Story: 2002544
Task: 22103
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
Parse each field in a resource definition individually instead of all in
one go. This allows the HOT and cfn formats to apply different parsing to
different fields - specifically in the future we want to parse the
condition field like a condition, using only the valid condition functions.
Change-Id: I5b864d241a5e16c09fcce30c40d634d9bb72e173
Ensure that the caching we do of conditions in TemplateCommon always
applies to the stack that has been passed in as an argument.
This was not the case previously, and in fact it was required not to be the
case because in the convergence path the new parameter values were not
copied into the stack at the start of an update. This patch rectifies that.
Change-Id: I942b53570222bf4e0d1bf78e584792d445c14090
Change the definitions of the Template.conditions() method to return a new
heat.engine.conditions.Conditions object. This class encapsulates the error
handling involved in looking up a condition, and lazily caches resolved
values so that conditions we never reference are not evaluated.
By raising ValueError instead of StackValidationFailed inside
Conditions.is_enabled(), we ensure that the user sees the full path to the
erroneous condition name if it appears inside the 'if' intrinsic function.
Change-Id: I266eec7e87d185182c4c0fea864e7ebdafa11bd5
Now that we raise them in only a single place each, there's not a lot of
value in having a custom exception type for condition-related errors in the
template any more, and in fact there was no code to handle them
appropriately in heat-api so it would have resulted in 500 errors to the
client if they ever escaped heat-engine anyway.
Just use the existing StackValidationFailed exception type. This provides
more flexible control over the path than InvalidConditionReference did.
Also, raising ValueError in the Invalid function means that
StackValidationFailed will be raised with the path, so it will be much
easier for users to find where they have used an invalid function.
Change-Id: Iaa6ca030fc144efc75e707910f84bfa7385fa9e2
Override the default Template.outputs() method (which is designed to mimic
how previous versions of Heat interacted with the Template) with a
Cfn/HOT-specific one, and mark the default implementation as deprecated.
This also allows us to considerably simplify the filtering out of outputs
based on conditions. Support for conditionals is removed from the default
implementation of Template.outputs(), since it didn't appear in any
previous release of Heat and therefore isn't needed for backwards
compatibility. (Third-party template format authors who want to implement
conditionals in the future - and those who don't - should override the
outputs() method.)
Change-Id: Iecf1ec9e0c467ec70ee9beeb9b02daccc8b8082c
Closes-Bug: #1618713
Following on from the deprecation of validate_resource_definitions() from
the Template interface, also remove validate_condition_definitions(). The
definitions will be validated when calling Template.conditions(), which
now occurs when loading the resource definitions, so it will still happen
during Stack.validate().
Since this interface is new and has never appeared in a release, we have no
need to go through a deprecation process.
Change-Id: I4dc36433c1aca776c2151205ed26a0f5241a750a
This allows us to parse the conditions only once instead of reparsing them
all every time we encountered a resource with a condition. It also allows
us to get rid of some of the API surface area and reduces our reliance on
some of the rest.
Partial-Bug: #1618713
Change-Id: I3c2273722171b9c4cb13ef6588f7b522b6689b1c
This method was added in order to be able to validate the resource
definitions during the Stack.validate() phase, and not have to wait until
the Resource objects are created. (It can't be done during
Template.validate() because the stack is not passed there, which is needed
to call Template.parse().)
However we actually already generate the ResourceDefinitions right below
this in Stack.validate() anyway, by virtue of creating the Resource
objects, so there was really never any reason to put it in a separate
method. It was actually much less efficient because we had to parse the
resource section of the template twice instead of once.
Accordingly, move the validation code into the resource_definitions()
methods and deprecate the validate_resource_definitions() method. (We have
to keep calling it for now, because third-party template formats may be
relying on this validation having been done before calling
resource_definitions().)
Change-Id: I76be34c5cf8500fca1654a066a5cead57b0e7bab
This is a utility function for validating the types of the various fields
in a resource definition during the validation phase, prior to creating the
ResourceDefinition object, that was added in
3f16eebd06.
Not only does this not belong in the public interface for all third-party
Template classes, but the implementation is nonsense. The verification code
must call it with a hard-coded key from the list of allowed keys along with
the allowed types for that value, and the method checks that the key is in
the list of allowed keys. (Surprise! It always is.) Meanwhile the keys
passed by the user are not checked for invalid values.
Fortunately the validity of the data passed by the user is checked
elsewhere as a side-effect of converting the resource definitions from HOT
to cfn, so we haven't been allowing bogus HOT templates since Kilo.
In the cfn-style templates we have never checked for invalid keys in the
resource definitions (and thus we can't really start), so the current
implementation was accidentally correct.
Since this is part of the public third-party interface we can't fix it
immediately. Instead, deprecate it and override it with a sane
implementation in the common parent class of HOT and CFN templates that was
added to hold such things. We'll remove it entirely from the public
interface later.
Change-Id: Ie38e8c62c5303f72a43f24fe1ace7ce8696abde1
We're supposed to be phasing out any code that still treats templates like
JSON data in favour of using the Template APIs. Since conditions are
already accessed only through the API, we should enforce that by adding it
to the list of keys that cannot be accessed directly in HOT and CFN.
Change-Id: Iea58c3d0fcc15f4834688c187319f40dc8691357
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
New an intermediate class named CommonTempalte to put the commont
implementation of HOT and CFN templates.
This patch move the resource definition validating to the
new class.
Change-Id: I96ce57d64f0649e309e40e75e573371bde917fbe
Blueprint: support-conditions-function
Stephen Finucane