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
We recently (I87edc0d8f1fba2fb61276c682a60c1b2241b5705) enforced default
type for software config input, whereas it was always a string before.
It causes issues with upgrades, as we used to store "" as a default for
all configs regarless of their type, and it failed when we started
validating.
This identifies this case and skip validation.
Change-Id: I8a4f4e834b0862ecef4b97f208f4b03be3572e86
Closes-Bug: #1697627
The default type for input was set to string, but it actually don't
match what's used for the type property. Set it to ANY to let the user
provide the proper value.
Change-Id: I87edc0d8f1fba2fb61276c682a60c1b2241b5705
Closes-Bug: #1687643
When the only way to define a Software Config was via a Heat resource, the
input and output configs were validated by the properties of the resource.
However, subsequently a REST API to create Software Configs directly was
added. That means that configs created in this way do not have the contents
of the inputs and outputs sections validated. This change adds validation
to ensure that the configs always follow the correct schema.
Change-Id: I8c66bb82484b75723524959be753a4cd20c0f84d
Stephen Finucane