I recently got my zero-dollar developer copy of Red Hat Enterprise Linux (RHEL, version 7.5) and built a virtual machine (VM) to run it. There it was, on my PC, running in VirtualBox…a gleaming, shiny, brand-spanking-new VM running RHEL. Whatever shall I do with it?
Then I got the idea: I’ll install the Red Hat Container Development Kit (CDK) and build some Python-based containers. I’ll use Flask, a terrific microframework that makes building RESTful services easy.
Continue reading “How to install Python Flask on Red Hat Enterprise Linux 7”
You can study source code and manually instrument functions as described in the “Use the dynamic tracing tools, Luke” blog article, but why not make it easier to find key points in the software by adding user-space markers to the application code? User-space markers have been available in Linux for quite some time (since 2009). The inactive user-space markers do not significantly slow down the code. Having them available allows you to get a more accurate picture of what the software is doing internally when unexpected issues occur. The diagnostic instrumentation can be more portable with the user-space markers, because the instrumentation does not need to rely on instrumenting particular function names or lines numbers in source code. The naming of the instrumentation points can also make clearer what event is associated with a particular instrumentation point.
For example, Ruby MRI on Red Hat Enterprise Linux 7 has a number of different instrumentation points made available as a SystemTap tapset. If SystemTap is installed on the system, as described by What is SystemTap and how to use it?, the installed Ruby MRI instrumentation points can be listed with the
stap -L” command shown below. These events show the start and end of various operations in the Ruby runtime, such as the start and end of garbage collection (GC) marking and sweeping.
Continue reading “Making the Operation of Code More Transparent and Obvious with SystemTap”
A common refrain for tracking down issues on computer systems running open source software is “Use the source, Luke.” Reviewing the source code can be helpful in understanding how the code works, but the static view may not give you a complete picture of how things work (or are broken) in the code. The paths taken through code are heavily data dependent. Without knowledge about specific values at key locations in code, you can easily miss what is happening. Dynamic instrumentation tools, such as SystemTap, that trace and instrument the software can help provide a more complete understanding of what the code is actually doing
I have wanted to better understand how the Ruby interpreter works. This is an opportunity to use SystemTap to investigate Ruby MRI internals on Red Hat Enterprise Linux 7. The article What is SystemTap and how to use it? has more information about installing SystemTap. The x86_64 RHEL 7 machine has
ruby-2.0.0648-33.el7_4.x86_64.rpm installed, so the matching
debuginfo RPM is installed to provide SystemTap with information about function parameters and to provide me with human-readable source code. The
debuginfo RPM is installed by running the following command as root:
Continue reading ““Use the dynamic tracing tools, Luke””
Red Hat Enterprise Linux continues to deliver the best possible experience for enterprise system administrators and developers, as well as provide a solid foundation for moving workloads into both public and private clouds. One of the ways to enable such ubiquity is Red Hat’s multi-architecture initiative, which focuses on bringing Red Hat’s software portfolio to different hardware architectures.
Last week, Red Hat Enterprise Linux 7.5 went live. It brought forward several improvements relevant to developers and system administrators such as advanced GUI system management via the Cockpit console, which should help new Linux administrators, developers, and Windows users to perform expert tasks without having to get into the command line.
This release also marks a new milestone for Red Hat Enterprise Linux: all supported architectures are now simultaneously enabled. The list of supported architectures includes x86_64, PowerPC Big Endian and Little Endian, s390x, and the more recently introduced 64-bit Arm and IBM POWER9 architectures.
Continue reading “Expanding architectural choices to better arm Red Hat Enterprise Linux developers”
If you’re running Red Hat Enterprise Linux server on Microsoft Azure, you may want to shut down and deallocate the VM using commands inside of the VM itself for automation or just for convenience. On Azure, if you shut down the VM by using
shutdown -h or another OS command, it will stop but not deallocate it. The stopped VM is still using resources and will continue to incur compute charges. To avoid that, this article shows how a VM can shut itself down and deallocate its resources using the Azure CLI 2.0.
Continue reading “Deallocate an Azure VM Using the Azure CLI on RHEL”
In a few weeks, the Fast Datapath Production channel will update the Open vSwitch version from the 2.7 series to the 2.9 series. This is an important change in more ways than one. A wealth of new features and fixes all related to packet movement will come into play. One that will surely be blamed for all your troubles will be the integration of the `–ovs-user` flag to allow for an unprivileged user to interact with Open vSwitch.
Running as root can solve a lot of pesky problems. Want to write to an arbitrary file? No problem. Want to load kernel modules? Go for it! Want to sniff packets on the wire? Have a packet dump. All of these are great when the person commanding the computer is the rightful owner. But the moment the person in front of the keyboard isn’t the rightful owner, problems occur.
Continue reading “Non-root Open vSwitch in RHEL”
In order to maximize performance of the Open vSwitch DPDK datapath, it pre-allocates hugepage memory. As a user you are responsible for telling Open vSwitch how much hugepage memory to pre-allocate. The question of exactly what value to use often arises. The answer is, it depends.
There is no simple answer as it depends on things like the MTU size of the ports, the MTU differences between ports, and whether those ports are on the same NUMA node. Just to complicate things a bit more, there are multiple overheads, and alignment and rounding need to be accounted for at various places in OVS-DPDK. Everything clear? OK, you can stop reading then!
However, if not, read on.
Continue reading “Open vSwitch-DPDK: How Much Hugepage Memory?”
I work at Red Hat on GCC, the GNU Compiler Collection.
My main focus for the last year has been on making GCC easier to use, so I thought I’d write about some of the C and C++ improvements I’ve made that are in the next major release of GCC, GCC 8.
Continue reading “Usability improvements in GCC 8”
You might think containers seem like a pretty straightforward concept, so why do I need to read about container terminology? In my work as a container technology evangelist, I’ve encountered misuse of container terminology that causes people to stumble on the road to mastering containers. Terms like containers and images are used interchangeably, but there are important conceptual differences. In the world of containers, repository has a different meaning than what you’d expect. Additionally, the landscape for container technologies is larger than just docker. Without a good handle on the terminology, It can be difficult to grasp the key differences between docker and (pick your favorites, CRI-O, rkt, lxc/lxd) or understand what the Open Container Initiative is doing to standardize container technology.
It is deceptively simple to get started with Linux Containers. It takes only a few minutes to install a container engine like docker and run your first commands. Within another few minutes, you are building your first container image and sharing it. Next, you begin the familiar process of architecting a production-like container environment, and have the epiphany that it’s necessary to understand a lot of terminology and technology behind the scenes. Worse, many of the following terms are used interchangeably… often causing quite a bit of confusion for newcomers.
- Container Image
- Image Layer
- Base Image
- Platform Image
Understanding the terminology laid out in this technical dictionary will provide you a deeper understanding of the underlying technologies. This will help you and your teams speak the same language and also provide insight into how to better architect your container environment for the goals you have. As an industry and wider community, this deeper understanding will enable us to build new architectures and solutions. Note, this technical dictionary assumes that the reader already has an understanding of how to run containers. If you need a primer, try starting with A Practical Introduction to Docker Containers on the Red Hat Developer Blog.
Continue reading “A Practical Introduction to Container Terminology”
If you are like me, you probably prefer to install new and exploratory software in a fresh virtual machine (VM) or container to insulate your laptop/desktop from software pollution (TM). Red Hat Container Development Kit (CDK) relies on virtualization to create a Red Hat Enterprise Linux (RHEL) virtual machine to run OpenShift (based on Kubernetes). Red Hat specifically supports installation of the CDK on Windows, macOS, and RHEL Server, but if you are running Fedora, RHEL Workstation, or even CentOS, you will run into trouble. If you are not running a supported desktop, you can always use a RHEL Server virtual machine, and this tutorial is for you.
Continue reading “Red Hat Container Development Kit (CDK) With Nested KVM”