Now that CFEngine 3.7.0 is released, introducing simplified package management, change management, dashboard sharing and enhanced network security, it’s time to look forward. The CFEngine 3.7 and 3.6 releases will mainly include stability and security enhancements as they are now stable branches. A blog-post on the release schedule going forward explains this in more detail. The next feature-release up is 3.8 (non-LTS), due for December 2015, and we’d like to share that performance will be the main release theme for 3.8! Secondly, we also plan to include support for phased rollout in 3.8.
Key performance metrics
CFEngine is typically deployed in a client-server fashion, where the Policy Server is a dedicated machine that is responsible for delivering the policy to the clients. So conceptually there are two types of CFEngine roles we could look at optimizing; the Policy Server or the client. However, as CFEngine clients are installed on nodes that do the valuable work of running application services, most users care the most about the performance of the client – so this is what we’ll focus on for 3.8. There are several metrics that we will measure and improve for 3.8, in prioritized order:
- Disk writes. This is very important in situations where CFEngine clients use shared storage; such as in OpenStack and other cloud environments. It is also important for lifetime of flash storage.
- CPU usage. CFEngine should let applications use as much of the CPU as possible. This is especially important in container environments.
- Memory usage. Likewise; as much memory as possible should be available to applications.
- Disk usage. Installation and run-time storage usage of CFEngine should be as low as possible; both for binaries and state data.
The first step is to measure status quo for these metrics with 3.7.0. We then plan to profile and optimize the areas that would benefit the most. We will know more hard numbers on what to expect in 3.8 once the measurements have been done; so watch for updates and contribute to improving client performance!
Phased rollout
Most Enterprise installations use some concept of environments in order to test changes before they’re released to production; normally dev, test and prod environments are used. As CFEngine is one of the key tools used to change Enterprise systems, we would like to better incorporate such workflows into CFEngine. There are a number of considerations to take into account; both with respect to the size and definition of the phases (do you want to release changes to all of production at once?), as well as the workflow (integration with version control systems) and isolation (is anything shared at all or is the policy and infrastructure completely isolated?). In general, choosing different aspects of these considerations generate tradeoffs with respect to ease of management and security/isolation. For example, if everything is shared and released everywhere at once then it is easy to manage but the isolation properties are poor. Which form this will take in CFEngine is something we will discover from your input; so if this is interesting make sure to watch for updates and contribute to phased rollout!
What this means for you
The obvious answer is that CFEngine users will see improvements in client performance and better management of rollouts for 3.8. However, if you are interested in contributing to CFEngine, we wanted to share the plans in order to improve collaboration with the CFEngine community. For example, it is more likely we can prioritize an issue report or pull request (be it in CFEngine core or masterfiles) that improves CPU utilization over one that adds support for a new promise type. Of course, we will still maintain and improve the stability of CFEngine, so any bugs will continue to be addressed. We hope you feel this is relevant and are happy to see your input in either of the two issues above, or in the CFEngine Google Group!
