Since we announced earlier about becoming the first Pakistani software company to have deployed a solution based on OpenStack, our team decided that they would like to share a behind-the-scenes look at the project and its implementation. Our Cypriot client’s requirements involved the design and development of a solution running on OpenStack that would result in the launch of their cloud-hosting provider business. The specifications of our client’s project involved the design and development of three primary business functions for the cloud-hosting provider business. End-Users selected that the first requirement was to support a straightforward installation of an instance according to the options (CPU cores, RAM, HDD). The application would suggest the best-recommended plan to the end-user based on their preferences.
The administrator is configuring the service types in our system. The second requirement was to support the installation of an instance. According to user-specified parameters with respect to the resources that would be assigned, as well as, supporting the upload of a database file. Depending on the end-users preference that file would be converted to and from either Firebird or MySQL. Then imported into the appropriate database server and would be installed once the initialization of the instance was completed. The third requirement was to support the installation of an instance according to user-specific parameters, but this time, the end-users would also be able to define and configure interval-based threshold alerts for the various resources of the instance, such as CPU and memory utilization.
Our specifications called for an extensively customizable range of input fields. When those resource utilization thresholds were exceeded for the specified intervals, the end-users would receive an email alert, and the original instance had to be automatically migrated to another newly-created instance with additional resources. This had to be accomplished by taking a snapshot of the volume of the original instance whose thresholds were exceeded, creating a second instance, and then attaching the snapshot of the original instance to the second instance. Additionally, the IP address assigned to the first instance from a floating pool of IP addresses would have to be detached from the original instance and then attached to the new instance when it had been initialized and was operational.
Solution
When we briefed the team on the specs, they started taking a look at the available SDKs for OpenStack. As almost all software developers know, the selection of an SDK requires carefully considering a range of factors such as its features, stability, and the quality of the codebase. With this in mind, the team also worked diligently to ensure that the client’s requirements were fully supported by the SDKs that were being considered for the implementation of the project. Ultimately, after having completed an exhaustive review of the options available to us, the team opted to work with the PHP SDK for OpenStack. This allowed us to leverage our years of experience in working with PHP so that we could get up and running within no time at all.
The administrator is configuring the operating system for the various services.
Further Steps
The team’s next steps were to go through the extensive documentation of OpenStack’s native functionality to get a handle on how they would go about integrating the different OpenStack APIs that were necessary to be able to implement the client’s requirements.It quickly became apparent that the implementation of the project specifications would require making extensive use of the following APIs provided by OpenStack:
- Identity API: The Identity service generates authentication tokens that permit access to the OpenStack services REST APIs. Clients obtain this token and the URL endpoints for other service APIs by supplying their valid credentials to the authentication service.
- Compute API: Through this API, the service provides massively scalable, on-demand, self-service access to compute resources.
- Networking API: The Networking API v2.0 is a RESTful HTTP service that uses all aspects of the HTTP protocol including methods, URIs, media types, response codes, and so on.
- Image Service API: Creates, lists, shows, updates, deletes, and performs other operations on images.
Once this was done, our team decided to integrate the PHP SDK for OpenStack with an application using Laravel, which is one of the, if not the most, popular frameworks for PHP today. Next, the team designed and developed the application itself to be able to offer a pleasant UI/UX experience to the client who would manage the backend as well as the client’s future customers.
An administrator is seen here configuring the instance packages. This turned out to be the most critical phase of the project, as the team ran into several issues that at the time seemed insurmountable. Almost all of the issues were related to the images used to deploy OpenStack instances. A significant number of the features specified in the client’s requirements required us to be able to prepare a Windows Server image and ensure the installation of several packages when the instance initialized with the image booted for the first time. Additionally, database files specified by users in the Laravel application had to be converted from and to the Firebird and MySQL database formats as well as imported once the installation of say, a database server was completed. The team considered the options that were available to them and decided on the integration of a 3rd party API from RebaseData to implement this part of the specifications.
The administrator is seen here setting up the initial fields for the instances
Conclusion
This would have been an easy task had the team been working with Linux-based images, but since the client’s specs called for Windows Server images, implementing this feature required extensive research into potential solutions. After a lengthy process of running tests, the Windows Server images for OpenStack were built properly using Cloudbase-Init, which is the Windows equivalent of the Cloud-Init project that is used on most OpenStack Linux images, and the team breathed a sigh of relief as they were able to successfully deliver these critical features. There were still moments during our sprints where we ran into a few troublesome issues that were caused by the limitations of the hosting provider where the Laravel application was running. One prime example of the limitation of the hosting provider being used by the client was their limit on the intervals at which cron jobs could run.
Since the OpenStack Networking API does not provide any webhooks for informing downstream applications when an IP address is assigned to the network ports of a newly initialized instance, and also because this information was important for our team to have access in the case of migrating an instance that had reached its resource threshold levels to another one, the team had to implement a 3rd party service named EasyCron to circumvent this limitation. The time our team took to be able to quickly troubleshoot these issues and implement several solutions that were able to get around these limitations was commended by our client. The implementation of the rest of the requirements was plain sailing, and several of the team members contributed towards implementing quite a number of enhancements to the application, as well as compiling the project’s documentation for the client. We hope you enjoyed reading this in-depth account of how our team delivered this rather complex project, and should you have any inquiries about a project that requires the OpenStack platform, we would absolutely love to hear from you!