Red Hat: Dstat, KubeVirt, Openwashing Banks and OpenShift 4

• Implementing Dstat with Performance Co-Pilot

  Dstat is a beloved tool by many, and a staple when diagnosing system performance issues. However, the original dstat is no longer actively developed. This poses an immediate problem for distributions like Fedora moving to a Python 3 stack, as it lacks a Python 3 implementation (both the tool itself, and its many plugins). It is also problematic in that the plugin system was relatively simplistic and in need of a significant redesign and rewrite to add new desired features.

• Re-Imagining Virtualization with Kubernetes and KubeVirt – Part II

  KubeVirt exposes a VirtualMachine entity in Kubernetes. This entity is persistent and defines the configuration of a virtual machine. This allows one to create, edit, start, stop, and start again a virtual machine (which one cannot do with a Kubernetes Pod). When the virtual machine is started, a VirtualMachineInstance is created, manifesting in Pod and Container in which the virtual machine runs. The VirtualMachine entity allows one to define virtual machines “the way you would expect it” from a virtualization expert’s perspective. You can name them, describe the virtual hardware devices, define multiple disks and networks. Expect to find your regular virtualization features here: CPU, memory, NUMA, CPU pinning, hugepages, CPU model selection, virtio-rng, memory overcommit, custom SMBIOS, cloud-init, boot order, serial console, graphical (VNC) console, custom PCI addresses for virtio devices, I/O threads, guest agent integration, and more being worked on.

• Why agile integration is key for open banking

  Many banks are striving to be more agile in their operations, their business practices, and even in their ability to innovate to deliver new products and services. With greater agility, banks can better meet the demands of today’s digital-savvy customers and excel in an increasingly competitive market. Initiatives like open banking can help facilitate that agility. Open banking uses open application programming interfaces (APIs) for third party developers, gives users greater transparency, and provides a model for the use of open source to build out solutions. We think that agile integration – bringing together containers, distributed integration, and APIs – is the best path to deliver open banking.

• OpenShift 4: A NoOps Platform

  In the previous post I described the goals that helped shape the OpenShift 4 vision. We want to make the day to day of software operations effortless – for operations teams and for developers. How do we make that goal – a NoOps platform for operations – a reality? What does “NoOps” mean in this context? At a ten thousand foot level, “Serverless” or “NoOps” for developers is characterized by tools and services that hide or minimize the operational burden from the developer. [...] That is why I am happy to announce the Developer Preview of OpenShift 4 is now available for public trial. This is a sneak peek of the next version of OpenShift, with an easy to use installer for starting a cluster on AWS on top of Red Hat CoreOS. The preview requires only credentials to an AWS account to provision infrastructure and a set of credentials to access the images for the preview.

Intel Preparing The Linux Kernel For Cascade Lake AP Multi-Die Support

Intel developers have begun posting their Linux kernel patches for enabling multi-die/package topology support to the Linux kernel as part of their Cascade Lake AP upbringing. Cascade Lake "Advanced Performance" is a multi-chip package of multiple Cascade Lake dies, expected to be up to 48 cores / 96 threads per package and twelve DDR4 memory channels. Cascade Lake SP and Cascade Lake X Linux support already has been in order -- or at least appears to be based upon previous commit activity -- while Cascade Lake AP is taking some additional work due to the new multi-die design. Cascade Lake dies are connected via Ultra Path Interconnect (UPI) links. Also: Linux Seeing Support For The HyperBus

Wayland 1.17 & Weston 6.0 Reach Alpha, Officially Releasing Next Month

Out today are the first alpha releases for Wayland 1.17 and the Weston 6.0 reference compositor. This alpha release is about two weeks behind schedule but the developers have updated their plans to now ship the beta releases on 5 March, release candidates begin on 12 March, and potentially releasing the stable versions of Wayland 1.17.0 and Weston 6.0.0 on 19 March. The Wayland 1.17 Alpha release adds to the protocol support for expressing an internal server error message as well as an updated wl_seat protocol. There are also memory leak fixes for the Wayland scanner and various test updates. Details on the 1.17 alpha via wayland-devel. Also out today is the Weston 6.0 Alpha. On the Weston compositor front they have shifted to using the Meson build system while deprecating Autotools, XDG-Shell stable support, FreeRDP 2.0 updates, IVI shell improvements, and many other changes.