VPS Manager for WHMCS - Provider-Neutral VPS Orchestration, Approaching First RC

[GoZen]

We are currently working on VPS Manager, a new module for the orchestration and management of VPS services within WHMCS, and the project is now nearing its first public release candidate.

The project was initiated because of the problems we continually encountered with the traditional WHMCS server modules- that is, the WHMCS product tends to become closely linked to one provider's API, terminology and provisioning model.

The VPS Manager works in a different way.

It sits between WHMCS and VPS providers and maintains its own provider-neutral model of:

• provider accounts and connectors
• discovered VPS inventory
• provider offerings
• technical resource profiles
• locations and physical capacity pools
• commercial sales routes
• WHMCS products
• service/resource assignments
• provisioning and lifecycle operations
• customer feature policies

Although netcup is the first connector, the system's core is intentionally not based on netcup-specific concepts.

Inventory and fulfilment

With the present netcup connector, VPS Manager identifies the infrastructure that is already available from the provider and then assigns machines that are eligible from that existing inventory whenever the WHMCS services need to be fulfilled.

A WHMCS product doesn't just amount to calling the provider's API and creating this server.

The VPS Manager starts by checking which physical resources are technically compatible, whether they are meant to be offered for sale, which commercial route the product is permitted to use, what location was ordered, and if the resource is still eligible at the time the allocation occurs.

Provisioning is checkpointed and can be resumed rather than being handled as a single CreateAccount request.

The activation sequence at present includes allocation, the installation of the operating system, the configuration of the hostname, the setting of the credentials and the final check to verify readiness. If a failure occurs after a VPS has been assigned, that resource is quarantined rather than having the possibly corrupted infrastructure silently returned to available capacity, and provisioning can continue from the point at which it had already been completed rather than allocating a new server.

Physical infrastructure and commercial routing are separate

A major architectural decision has been to separate the physical topology from the thing that you decide to sell.

The technical Resource Profiles and physical Pools are used to represent provider infrastructure.

The capacity is used up by WHMCS products via Allocation Groups / Sales Routes.

It thereby enables compatible physical infrastructure to support various commercial products without having to claim that the names of the products or the names of the packages provided define technical equivalence.

The location is also treated separately since the physical location of a VPS and the location where a WHMCS product is offered are related but not identical.

WHMCS integration

The current development build includes work around:

• location-aware ordering
• WHMCS configurable-option based VPS location selection
• regional location pricing
• operating-system selection
• controlled existing-service adoption
• provisioning queue and durable waiting states
• service life cycle management
• customer power and server-management controls
• credential reveal and controlled password reset
• friendly server naming separately from technical hostname
• product configuration health and drift detection
• reconciliation when provider inventory changes

There is also an optional on-demand order-admission model. This model does not imply that the VPS Manager automatically buys a VPS from the provider; instead, it enables an operator to accept an order in accordance with a defined supplier-availability policy and keep the service stated as Pending until some of their own capacity becomes available.

The process of procuring providers is still separate from the process of allocating them.

Where we are now

We are at the last stage of development and regression before the first public RC.

At this stage the emphasis is not on adding more headline features but on tightening the lifecycle behaviour, arranging for recovery, carrying out upgrades, integrating with WHMCS, preparing the documentation and improving the release process itself.

We are also going to transfer the project to a workflow that involves creating a formal issue, then a branch, followed by testing and review, so that the source commit used to produce an RC is the same as the source from which the release package is made.

The first RC will be concerned with the netcup connector and further providers are deliberately being left out until the core and the first connector have been properly used in real WHMCS workflows.

I'm going to use this thread to post updates regarding developments and RC versions rather than opening a new topic for each build.

I should also like to know, if you're providing VPS products via WHMCS, especially if you're using netcup or looking after existing provider inventory, which sections of the provisioning and life-cycle workflow currently cause you the most difficulty.

[GoZen]

A quick development update since the original post.

VPS Manager has now moved into what I would describe as release preparation rather than normal feature development.

A lot of the recent work has come from qualifying the module on a fresh WHMCS installation rather than only on the long-lived development environment. That has been particularly useful for finding portability and onboarding issues which aren't necessarily visible after a module has been upgraded repeatedly during development.

Some of the areas tightened during this pass include:

• fresh-install/database compatibility;

• Setup Center and first-run onboarding;

• existing VPS adoption and reconciliation;

• separation of existing-service adoption from Pending/new-service provisioning;

• product configuration/drift diagnostics;

• provider API error reporting and source-IP restriction diagnostics;

• customer credential and lifecycle handling;

• welcome-email timing after asynchronous provisioning.

One useful addition from the provider testing is a public outbound-IP diagnostic. For WHMCS installations behind Cloudflare/NAT, for example, the IP a provider sees for outbound API requests obviously isn't necessarily related to the IP serving the WHMCS website. VPS Manager can now surface that information when configuring provider-side source-IP restrictions.

We have also started the release-engineering side properly now.

The production distribution will use ionCube-protected PHP together with VPS Manager's software licensing, and I'm currently setting up the reproducible build and customer licensing/delivery process. The intention is that an RC is generated from an exact frozen source revision rather than simply packaging whichever development tree happens to be current.

The first RC will still focus only on the netcup connector.

One change to the rollout plan is that we are going to qualify the first RC internally across several separate WHMCS installations before making a build available more widely. That should give us a better test of clean installation, licensing, provisioning and upgrades before asking anyone else to run it.

At this point I'm deliberately trying not to add another layer of headline features before the first RC. The priority is making the existing lifecycle predictable and making sure a new WHMCS administrator can actually understand the configuration without having to know how VPS Manager is built internally.

I'll keep posting the meaningful milestones in this thread as we work through the RC qualification.