Current Series Release Notes

18.0.0.0b1-252

New Features

  • You can set a private repository for epel, you must use lxc_centos_epel_mirror for the repo URL and if you need to get the GPG key from intranet or a mirror use lxc_centos_epel_key for gpg key location.

  • Implemented variable lxc_image_cache_expiration that controlls for how long cached LXC image will be valid. Default value is 1year. Variable format should be compatible with community.general.to_time_unit filter.

  • The lxc_hosts role now supports the ability to omit lxc network interface deployment. The option lxc_net_managed is a Boolean operator and defaults to true. When this option is set to false the role will not deploy an interface file or attempt to manage the state of the interface.

  • An option to disable the machinectl quota system has been changed. The variable lxc_host_machine_quota_disabled is a Boolean with a default of false. When this option is set to true it will disable the machinectl quota system.

  • The options lxc_host_machine_qgroup_space_limit and lxc_host_machine_qgroup_compression_limit have been added allowing a deployer to set qgroup limits as they see fit. The default value for these options is “none” which is effectively unlimited. These options accept any nominal size value followed by the single letter type, example 64G. These options are only effective when the option lxc_host_machine_quota_disabled is set to false.

Upgrade Notes

  • All supported operating systems now build their LXC images locally on the lxc container hosts rather than relying on external pre-built base images. debootstrap and dnf are used on debian and Centos variants respectively. All variables controlling the download of images have been removed from the lxc_hosts role, and a new override, lxc_apt_mirror is added to allow local mirrors to be specified for debootstrap. Centos systems will use the mirror configuration already present on the host when building the container rootfs with dnf.

  • The variable lxc_cache_map is removed as the lxc_hosts ansible role has only been able to create containers matching the host architecture and OS for several releases, and lxc_cache_map simply carried copies of data from ansible_facts.

Deprecation Notes

  • To provide compatibility with Centos-8 the LXC cache preparation has been greatly simplified to remove the requirement for machinectl and btrfs, which is a combination not available on Centos-8. This has the side effect of machinectl no longer being a supported backing store for LXC.

  • SSHD and rsync are no longer installed or configured for all containers. This also deprecates usage of lxc_container_ssh_key and variable has no effect any longer.

Bug Fixes

  • Newer releases of CentOS ship a version of libnss that depends on the existence of /dev/random and /dev/urandom in the operating system in order to run. This causes a problem during the cache preparation process which runs inside chroot that does not contain this, resulting in errors with the following message.

    error: Failed to initialize NSS library
    

    This has been resolved by introducing a /dev/random and /dev/urandom inside the chroot-ed environment.

  • LXC image cache expiration mechanism has being fixed. Previously LXC images were valid forever.

  • Since Ubuntu has dropped older base images, which resulted in all previous tags being broken, we’ve switched to downloading always latest base image available. This should guarantee that we retrieve relevant images only.

  • With the release of CentOS 7.6, deployments were breaking and becoming very slow when we restart dbus in order to catch some PolicyKit changes. However, those changes were never actaully used so they were happening for no reason. We no longer make any modifications to the systemd-machined configuration and/or PolicyKit to maintain upstream compatibility.

18.0.0.0b1

New Features

  • The variable lxc_user_defined_container has been added to the lxc_hosts role allowing deployers to define the variable file loaded when preparing a base container image. This option defaults to using a base image most closely associated with the underlying OS however should a deployer need, this option can be used to customize the base container image for a given host.