If you are developing with C/C++, Clang tools and newer versions of GCC can be quite helpful for checking your code and giving you better warnings and error messages to help avoid bugs. The newer compilers have better optimizations and code generation.
You can easily install the latest-supported Clang and GCC compilers for C, C++, Objective-C, and FORTRAN using
yum on Red Hat Enterprise Linux. These compilers are available as software collections that are typically updated twice a year. The May 2018 update included Clang/LLVM 5 and GCC 7.3, as well as Go and Rust.
If you want your default
gcc to always be GCC 7, or you want
clang to always be in your path, this article shows how to permanently enable a software collection by adding it to the profile (dot files) for your user account. A number of common questions about software collections are also answered.
Continue reading “How to install Clang/LLVM 5 and GCC 7 on RHEL”
The most common problem when people are trying to deploy an Open vSwitch with Data Plane Development Kit (OvS-DPDK) solution is that the performance is not as expected. For example, they are losing packets. This is where our journey for this series of blogs will start.
This first blog is about Poll Mode Driver (PMD) thread core affinity. It covers how to configure thread affinity and how to verify that it’s set up correctly. This includes making sure no other threads are using the CPU cores.
Continue reading “Troubleshooting Open vSwitch DPDK PMD Thread Core Affinity”
This article is about debugging out-of-memory issues with Open vSwitch with the Data Plane Development Kit (OvS-DPDK). It explains the situations in which you can run out of memory when using OvS-DPDK and it shows the log entries that are produced in those circumstances. It also shows some other log entries and commands for further debugging.
When you finish reading this article, you will be able to identify that you have an out-of-memory issue and you’ll know how to fix it. Spoiler: Usually having some more memory on the relevant NUMA node works. It is based on OvS 2.9.
Continue reading “Debugging Memory Issues with Open vSwitch DPDK”
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”
Today I want to talk about Ansible Service Broker and Ansible Playbook Bundle. These components are relatively new in the Red Hat OpenShift ecosystem, but they are now fully supported features available in the Service Catalog component of OpenShift 3.9.
Before getting deep into the technology, I want to give you some basic information (quoted below from the product documentation) about all the components and their features:
- Ansible Service Broker is an implementation of the Open Service Broker API that manages applications defined in Ansible Playbook Bundles.
- Ansible Playbook Bundles (APB) are a method of defining applications via a collection of Ansible Playbooks built into a container with an Ansible runtime with the playbooks corresponding to a type of request specified in the Open Service Broker API specification.
- Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.
Continue reading “Customizing an OpenShift Ansible Playbook Bundle”
[In case you aren’t following the OpenShift blog, I’m cross posting my article here because I think it will be of interest to the Red Hat Developer commnity.]
The Open Service Broker API standard aims to standardize how services (cloud, third-party, on-premise, legacy, etc) are delivered to applications running on cloud platforms like OpenShift. This allows applications to consume services the exact same way no matter on which cloud platform they are deployed. The service broker pluggable architecture enables admins to add third-party brokers to the platform in order to make third-party and cloud services available to the application developers directly from the OpenShift service catalog. As an example AWS Service Broker created jointly by Amazon and Red Hat, Azure Service Broker created by Microsoft and Helm Service Broker created by Google to allow consumption of AWS services, Azure services and Helm charts on Kubernetes and OpenShift. Furthermore, admins can create their own brokers in order to make custom services like provisioning an Oracle database on their internal Oracle RAC available to the developers through the service catalog.
Continue reading “Using Ansible Galaxy Roles in Ansible Playbook Bundles”
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””
We are pleased to announce the general availability of:
- Red Hat Software Collections 3.1 (including Ruby 2.5, Perl 2.26, PHP 7.0.27, PostgreSQL 10, MongoDB 3.6, Varnish 5, HAProxy 1.8, Apache 2.4 update)
- Red Hat Developer Toolset 7.1 (GCC 7.3)
- Clang/LLVM 5.0, Go 1.8.7, Rust 1.25.0
Continue reading “Announcing GA for latest Software Collections, Developer Toolset, Compilers”
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”