Articles

Not all parameters are described in the article, but only those that you usually need to change when configuring new CloudStack clouds that use the KVM hypervisor. The parameters for the KVM host are applied when configuring the host and after each reload of the cloudstack-agent.

CloudStack version: 4.11.1

You can change the settings in the configuration file on the virtualization node: /etc/cloudstack/agent/agent.properties

Many parameters are described in the documentation Apache CloudStack. A full list of parameters with comments can be found in Git-repository CloudStack. Because not all parameters are documented, you can also find some of them in the source code. The parameters described below are recommended to be specified after the successful addition of the host to the cloud, but before the provisioning of virtual machines.

The article describes not all the parameters, but only those that you usually need to change when configuring new CloudStack clouds. The settings for the cluster are applied without restarting the CloudStack management servers and only affect the cluster for which it is installed.

CloudStack Version: 4.11.1

The parameters descibed in the article can be configured at: Infrastructure / Clusters / Cluster Name / Settings Tab

If you face the requirements to run a big bunch of environments for a single app, if you work with microservice architectures, have diverse of apps or an environment where an app is deployed for every tennant, if you develop a high performance scalable application, it means that DC/OS is what you should pay attention to.

— We will code tests later...
— Sorry, I’m not going to buy it.

Probably you are a programmer, a chief or a customer. The most important thing is that you are connected with software development, and just today you said it yourself or heard from someone something like that:

• Now, we are developing the code, but we will develop tests later since currently, everything is changing. But as soon as changes stop, we will implement them immediately.
• Let’s skip test design because it will slow us down. In this case, we will be able to move forward much faster.
• Unfortunately, we don’t have any time for implementing tests, so we will develop only code… If we have time, we will do it.

There are many variations, but a result is almost always the same – later or never. When we are at the beginning of our career path, we are young, full of strength, self-confident, our judgment isn’t clouded, we are steeled by struggling with university laboratory researches, on which we worked all last days and maybe even weeks. It seems like the sky’s the limit for us. And we code so fast, that nothing is necessary but paper and that’s it. What tests, I beg you. It’s much faster to do it on your own rather than explain how to do it. Neglect of testing is growing inside: “It’s for losers, I don’t need it as I already develop it perfectly without it.“

When using DC/OS in scalable systems, tens or even hundreds of servers are often used. As necessary or in emergency situations, the nodes reboot, in this case the DC/OS frameworks determine the unavailability of tasks and start them on other live nodes or wait when the disconnected nodes are online again and restart the stopped tasks on them.

Sometimes this leads to the appearance of tasks in exotic states that can not be removed by both UI and DC/OS CLI tools.