Managed OpenStack and Kolla-Ansible Services

Supported versions are confirmed during discovery based on lifecycle status, deployment method, dependencies, and upgrade requirements. Older releases can usually still be operated and monitored, but an upgrade path is discussed where a version is past upstream maintenance.

Kolla-Ansible is the primary specialty and where the deepest lifecycle support applies. Other deployment methods can be assessed and monitored, and the level of operational support is confirmed during discovery once the deployment tooling is known.

Yes. That is the normal starting point. The infrastructure assessment establishes current state, risks, and monitoring gaps first, so operations begin from a documented baseline rather than assumptions.

Yes. Where no monitoring exists, Prometheus, Alertmanager, Grafana, and the relevant exporters can be deployed and configured as part of onboarding. Where monitoring already exists, the work is usually coverage and alert-quality improvement instead.

Yes. Existing Prometheus, Grafana, or third-party platforms can be extended with OpenStack-specific targets, dashboards, and alert rules. Alertmanager can also route into an existing on-call or ticketing system.

Coverage hours and response targets are customized and confirmed in the service agreement. They are not fixed in advance, and no round-the-clock commitment is implied until it is written into your agreement.

Yes, as a planned project rather than routine maintenance. Upgrades include version-compatibility assessment, pre-upgrade validation, a rollback plan, an agreed maintenance window, and post-upgrade validation. Nothing is upgraded without testing and your approval.

The service can monitor Ceph and support its integration with OpenStack, including Cinder, Glance, and Nova storage paths. Deep Ceph cluster administration — rebalancing, CRUSH map changes, and capacity operations inside the Ceph cluster itself — must be explicitly included in scope.

Yes. Compute scheduling failures, agent outages, and volume-service problems are core incident categories. Diagnosis works from Placement inventory, agent state, queue depth, and service logs rather than blind restarts.

Access uses named accounts and key-based authentication through a path you control, and you can revoke it at any time. Activity is logged, and access is scoped to what the agreed scope requires.

No. Production changes follow an agreed change process with a defined window and rollback criteria. Emergency actions during an active incident follow the escalation path agreed in your service agreement.

The environment is reviewed across architecture, service health, Kolla-Ansible configuration, monitoring coverage, capacity, certificates, backup and recovery, upgrade readiness, and single points of failure. You receive an executive summary, current-state findings, critical risks, and a prioritized remediation plan.

Yes. Multi-region and multi-site environments can be supported. Region count affects monitoring topology, onboarding effort, and scope, so it is captured during discovery.

Yes. Capacity and utilization summaries are part of the monthly reporting, covering compute allocation, oversubscription, and storage headroom, with forecasting available at the higher engagement levels.

Onboarding timing depends on current availability, access provisioning on your side, and the outcome of the assessment. The discovery call is normally the fastest way to get a realistic date for your environment.