Provider guides
VirtFusion: configuration and operations
An experimental connection and product-schema adapter for VirtFusion.
On this page
Provider workflow
An experimental connection and product-schema adapter for VirtFusion. It belongs to the Provisioning module but is not available for production service delivery. Its product draft contains plan_id, template_id, location_id. This catalogue entry documents the source boundary, not a working automated hosting offer.
Requirements
Agovena Core ^0.0.1. Enable Provisioning before this extension.
This extension is not marked production-ready. Validate its supported workflow in your own test environment before accepting customer orders.
Set up the package
Keep the extension disabled for customer-facing products. In an isolated development installation, enable Provisioning first and review the declared VirtFusion connection fields. Store credentials only in the protected server settings and leave verify_tls enabled. The connection timeout defaults to 20 seconds. Do not send real customer orders to this adapter.
Provider-specific boundaries
The draft product mapping separates plan_id, template_id and location_id, while connection settings hold the endpoint and token. The HTTP class uses bearer authentication and a generic /api/v1/servers collection. Select the API reference matching your VirtFusion installation when implementing the missing lifecycle, rather than guessing that these field names are the full vendor payload.
The following configuration contract is useful for developers planning the integration, not as a production setup recipe. Required fields describe the draft connection form; the product fields above do not have required validation in their definitions. The shared client calls /api/health for its connection test. A green response there does not exercise account creation, ownership checks, cancellation or resource accounting.
Before offering this provider to customers, a provider-specific implementation must replace the unsupported lifecycle and demonstrate the intended vendor requests, response validation, resource ownership and recovery behavior. Keep a manual fulfillment process or choose a separately validated adapter meanwhile. Do not bypass the unsupported guard, disable TLS checks or point the API URL at a different service merely to satisfy the health probe. 2
Configuration contract
| Field | Type | Required | Secret | Default |
|---|---|---|---|---|
api_url |
string |
Yes | No | Empty |
api_token |
string |
Yes | Yes | Empty |
verify_tls |
boolean |
No | No | true |
timeout |
string |
No | No | "20" |
These are the declared manifest fields. A field marked optional may still be required by an API operation, as described above. Store secret values only in protected settings, never in product descriptions, URLs or shared examples. 1
Operation and failure handling
Provisioning, activation, suspension, reactivation, termination, plan changes, status synchronization and panel actions deliberately raise an unsupported-operation validation error through the shared base class. Capacity lookup is also unsupported in the shared HTTP client. A health request can run, but successful connectivity does not unlock these operations or prove vendor API compatibility.