Openstack Laravel Package

Product Decisions This Supports

• Build vs. buy for OpenStack access. Rather than hand-rolling raw Guzzle clients against Keystone, Nova, Neutron, Cinder, Glance, Swift, and Gnocchi, the team consumes a maintained, semver-versioned SDK. This shifts engineering from protocol plumbing to product differentiation.
• Roadmap for private/sovereign/hosted-cloud features. Enables roadmap items like tenant self-service portals, VM lifecycle management, volume attach/detach, floating IP management, object storage for user assets, server groups, and application-credential-based automation — all from an existing PHP/Laravel codebase without adding a second runtime (Python/Go) to the org.
• Feature scoping and delivery estimates. Service coverage (documented in COVERAGE.md) directly maps to what can ship quickly. Compute, BlockStorage, Networking, Images, ObjectStore, Identity, and Gnocchi are the near-term addressable surface; anything outside that coverage is custom work.
• Investment sizing — the 20/80 split. The SDK is the cheap part. The real product cost is the Laravel adapter layer: service provider, credential/config resolver, token cache, exception mapping, retry and compensation logic, queued provisioning workflows, and observability. Budget this explicitly in the roadmap or the feature will slip.
• Architecture decision: adapter, not domain layer. Decide now that SDK models never leak into controllers, jobs, or views. This protects the product from OpenStack API drift and keeps a future migration path (or multi-cloud abstraction) open.
• Risk posture and maintenance ownership. With a small maintainer base and community-only support, the PM decision is "adopt with a fork-and-patch contingency," not "set and forget." Allocate a named owner and a dependency-upgrade cadence.
• Explicit non-goals. This package should not anchor a cloud-portability strategy, a multi-cloud abstraction, or ultra-low-latency data paths. Recording those as non-goals prevents scope creep later.

When to Consider This Package

Adopt when:

• The application already runs on — or must integrate with — OpenStack (private, sovereign, or OpenStack-based hosted cloud), and the stack is PHP/Laravel.
• The required services and microversions are listed in the SDK's COVERAGE.md and are validated against your specific cloud's endpoint catalog and region configuration.
• Runtime constraints align: PHP >= 7.2.5, ext-curl, and a Laravel version whose Guzzle/uri-template constraints resolve cleanly. Recent releases added PHP 8.4 support and fixed the uri-template and Guzzle promises conflicts that previously broke Laravel installs — pin and test early.
• You only need synchronous API calls wrapped in your own queued jobs. Long-running operations (server create, volume attach, snapshots, large object uploads) are fine, provided you own the async orchestration.
• The organization accepts community-only support and can afford to fork or contribute upstream. Apache-2.0 makes this legally and practically viable.

Look elsewhere when:

• The requirement is multi-cloud or hyperscaler portability (AWS/GCP/Azure). This SDK is OpenStack-specific and offers no abstraction layer.
• The team expects a Laravel-native experience — facades, publishable config, first-class service provider. None exists; that integration is your build.
• A vendor SLA, indemnification, or commercial support contract is a procurement requirement.
• The workload is latency-sensitive or high-throughput at the data plane, where a thin HTTP abstraction still adds overhead.
• Your OpenStack release is unmaintained — the SDK has dropped CI support for end-of-life OpenStack versions, so you may be on your own.
• Dependency resolution conflicts with a locked-down Laravel/Guzzle stack cannot be resolved without a framework upgrade.
• Packagist reports 0 dependents. Treat ecosystem maturity as unproven: require a one-service proof of concept before committing the roadmap.

How to Pitch It (Stakeholders)

To executives: We can deliver OpenStack-backed features — VM provisioning, storage, networking, tenant self-service — from our existing PHP team and codebase, with no new language, no new hires, and no license cost (Apache-2.0). Time-to-market is weeks, not quarters. The trade-off is a small open-source community: we mitigate by isolating the SDK behind our own interfaces, keeping a fork option open, and validating with a scoped two-sprint spike on one service before wider commitment. Decision requested: fund the spike, then a go/no-go.

To engineering: It is an idiomatic, semver-versioned PHP SDK with declarative service APIs, Keystone authentication (including application credentials and token validation), and current PHP 8.4 support. It aligns with our Composer/Guzzle/PSR-7 stack. We will bind client factories and per-service adapters through the service container, map SDK exceptions to domain errors, cache tokens, and run all long-running operations through queued jobs with idempotency and orphan-resource cleanup. Nothing from the SDK escapes the adapter boundary.

To security and platform: Authentication is Keystone-oriented and supports application credentials and token validation, which fits multi-tenant and least-privilege patterns. Credentials live in config, not code. The primary residual risk is supply chain: a narrow maintainer base — addressed through version pinning, automated dependency scanning, and a documented fork procedure.