This makes the following changes:
- The `append_newline` argument to the `file.blockreplace`
remote-execution function has been modified so that if its value is
`None`, it only appends a newline when the content block does not end
in one.
- A couple of fixes were made to newline handling. The existing code
normalized the newlines in the content block, replacing them with
os.linesep. However, when the file contains newlines that don't match
the OS (i.e. POSIX newlines in a file on a Windows box, or Windows
newlines on a Linux/Mac/BSD/etc. box), then we would still end up with
mixed newlines. The line separator is now detected when we read in the
original file, and the detected line separator is used when writing
the content block. Additionally, the same newline mismatch was
possible when appending/prepending the content block. This has been
fixed by using a common function for appending, prepending, and
replacing the content block.
- Support for the `append_newline` argument has been added to the
`file.blockreplace` state. The default value for the state is `None`.
A `versionchanged` has been added to the remote execution function to
let users know that the Fluorine release will change the default value
of that variable.
- 20 new integration tests have been written to test the
`file.blockreplace` state.
This makes the following changes:
- The `append_newline` argument to the `file.blockreplace`
remote-execution function has been modified so that if its value is
`None`, it only appends a newline when the content block does not end
in one.
- A couple of fixes were made to newline handling. The existing code
normalized the newlines in the content block, replacing them with
os.linesep. However, when the file contains newlines that don't match
the OS (i.e. POSIX newlines in a file on a Windows box, or Windows
newlines on a Linux/Mac/BSD/etc. box), then we would still end up with
mixed newlines. The line separator is now detected when we read in the
original file, and the detected line separator is used when writing
the content block. Additionally, the same newline mismatch was
possible when appending/prepending the content block. This has been
fixed by using a common function for appending, prepending, and
replacing the content block.
- Support for the `append_newline` argument has been added to the
`file.blockreplace` state. The default value for the state is `None`.
A `versionchanged` has been added to the remote execution function to
let users know that the Fluorine release will change the default value
of that variable.
- 20 new integration tests have been written to test the
`file.blockreplace` state.
This preserves the custom mock_open we backported from unittest.mock,
but otherwise ditches unittest.mock as it does not have
MagicMock.assert_called in Python releases before 3.6.
This allows us to maintain a uniform mock version across all platforms
and Python releases.
Some of these have been failing in ways which are not reproducible
locally. This adds debug logging so that we can check the
salt-runtests.log for the return data, to aid in troubleshooting.
NOTE: This also contains a fix for a bug in the CLI output handler that
I think may have a chance of fixing some of these odd failures.
https://github.com/saltstack/salt/pull/45687 and
https://github.com/saltstack/salt/pull/45725 fixed problems with older
Python 2 versions interacting with the struct module, since
unicode_literals turned the format strings to unicode and older Python 2
releases can't accept a unicode format string. Since Python 2 and 3 both
support using bytestrings for the format strings, this commit makes sure
we are using bytestrings everywhere else we are using struct.pack/unpack.
Without allow_unicode=True, unicode characters are processed through the
str representer and on Python 2 are dumped as a Unicode code point (i.e.
a literal \u0414). This commit makes allow_unicode=True the default in
our salt.utils.yamlloader.safe_dump() helper. It also adds a new
salt.utils.yamlloader.dump() helper which wraps yaml.dump() and also
makes allow_unicode=True the default.
To make importing and using our custom yaml loader/dumper easier, a
convenience module called salt.utils.yaml has been added, which does a
wildcard import from both salt.utils.yamldumper and
salt.utils.yamlloader.
Refs to yaml.load/dump and yaml.safe_load/safe_dump have been updated to
salt.utils.yaml, to ensure that unicode is handled properly.
When CherryPy run with python3 it reads "bytes" from the wire.
In case of python2 BytesIO == StringIO, so nothing should change.
This change will do the same to make unit tests reflect reality.
Python 3 does not appear to pass all values to the `__import__` builtin
when they do not differ from the defaults. Therefore, the fake import
fails because of missing positional args.
This fix simply uses the defaults from Python 2 and 3's `__import__`
builtin.
This makes the 2.x usage invalid syntax and forces the use of print as a
function. This adds the import to the files which I've updated in the
last couple of days but forgot to add it.
Much Improved Support for Docker Networking
===========================================
The `docker_network.present` state has undergone a full rewrite, which
includes the following improvements:
Full API Support for Network Management
---------------------------------------
The improvements made to input handling in the
`docker_container.running` state for 2017.7.0 have now been expanded to
docker_network.present`. This brings with it full support for all
tunable configuration arguments.
Custom Subnets
--------------
Custom subnets can now be configured. Both IPv4 and mixed IPv4/IPv6
networks are supported.
Network Configuration in :py:func:`docker_container.running` States
-------------------------------------------------------------------
It is now possible to configure static IPv4/IPv6 addresses, as well as
links and labels.
Improved Handling of Images from Custom Registries
==================================================
Rather than attempting to parse the tag from the passed image name, Salt
will now resolve that tag down to an image ID and use that ID instead.
Due to this change, there are some backward-incompatible changes to
image management. See below for a full list of these changes.
Backward-incompatible Changes to Docker Image Management
--------------------------------------------------------
Passing image names to the following functions must now be done using separate
`repository` and `tag` arguments:
- `docker.build`
- `docker.commit`
- `docker.import`
- `docker.load`
- `docker.tag`
- `docker.sls_build`
Additionally, the `tag` argument must now be explicitly passed to the
`docker_image.present` state, unless the image is being pulled from a
docker registry.
