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.