2 of 8

Heat

Project Snapshot

OpenStack Orchestration

# of Contributors (Mitaka)

# of Companies

(Mitaka)

184

Mitaka (28 specs & 9 blueprints)

Newton

Ocata

Convergence Engine Finalization
Convergence Engine Phase 2 - Healing
Condition Functions

Scalability - Parallelization from Convergence Engine
Reliability - Improved Stack Resiliency via Healing

Initial Convergence Phase 1
Support for Senlin Resources
OpenStack Client Support

https://etherpad.openstack.org/p/PWG-Q12016-Roadmap-Refresh-Heat

What are the most significant two or three features or enhancements that [Heat] will deliver in the Mitaka release?

Openstackclient support
support for Senlin resources
Mostly done (90 %) "Convergence" feature.
Most blockers have been fixed
Missing performance and corner cases
Plan to enable convergence testing via TripleO

Why are these features or enhancements important to users?

First feature is the part of common migrations all clients to openstackclient and it's more useful, when all functions available in one general place.
These new resources should allows to execute more flexible/tricky autoscaling, then currently presented in Heat. May be in some far future it will be used instead of Heat autoscaling.
It's the one of the long time desired features, because allows to improve Heat scalability and solve some known architecture limitations (issues).
Improves scalability when creating resources in parallel

Looking ahead to Newton’s release in seven months, what significant features do you anticipate [project] will start/ stop/ continue to develop?

Finishing "Convergence" (Phase 1) and maybe Phase 2, which is focused on healing resources.
Phase 1 - Parelleization
Phase 2 - Healing when doing stack update
Condition Functions - Used in templates to add logic to template (if this parameter, ignore that resource)

Looking ahead one year to the Ocata release, which of the following themes will be most significant in Heat'sdevelopment? (Themes: Modularity, Manageability, Scalability, Resiliency, Interoperability)

I think, that it will be Scalability and Resiliency
Resiliency - Comes from Phase 2 healing

3 of 8

Ansible

Project Snapshot

$shortDescription

# of Contributors (Mitaka)

# of Companies

(Mitaka)

103

Mitaka (29 specs & 22 blueprints)

Newton

Ocata

Multi-region Support
Additional Services - Magnum, Barbican, Designate, Searchlight, Gnocchi, Zaqar
MultiOS Support - Ubuntu 16.04LTS

Interoperability with other projects
Continued increases in modularity, manageability and scalability

Modularity - Roles into new independent repositories, deploy from source
Reliability - Increased test coverage, with full multi-node gate test
Additional Services - LBaaSv2, Ironic

PTL Interview - Mitaka Design Series (Video)

https://etherpad.openstack.org/p/openstack-ansible-newton-roadmap-refresh

What are the most significant two or three features or enhancements that OpenStack-Ansible will deliver in the Mitaka release?

Increased modularity:

The Ansible roles we provide deploy OpenStack services from source, and deploy their key infrastructure dependencies.

For Mitaka we have broken the roles out into their own repositories in order to allow deployers to make use of them with their own Ansible playbooks.

Increased test coverage:

While we still have full integration testing on every commit to ensure that the deployment of OpenStack by OpenStack-Ansible's playbooks really works, we increased test coverage for the individual roles in order to increase the test coverage, improve code quality, reduce regressions and to cover more difficult test cases (eg: the major version upgrade of MariaDB).

Additional services:

OpenStack-Ansible can now deploy Ironic as an additional Nova hypervisor in order to provision Bare Metal instances.

Neutron LBaaSv2

We have some more in the wings - Magnum, Barbican, Designate, Searchlight, Gnocchi, Zaqar -we're not sure if they'll be ready for the Mitaka release.

Why are these features or enhancements important to users?

There is no one-size-fits all way that OpenStack can be deployed at scale. Providing ways for our roles to be used independently of our playbooks allows deployers to have more freedom in their architecture choices, and to cater for environments which need more modularity.

Consider the use-case of an environment where the team managing the database for the OpenStack environment is not the same team that manages the OpenStack Services. With the improved modularity we're providing, deployers can easily accomodate scenario's like this.

Consider the use-case of deploying directly from the trunk of OpenStack's service git repositories (or a local fork of them). For many deployment tools this is just not possible. Beyond the simple deployment from source this scenario would require a lot of tooling around the deployment in order to handle the CI/CD processes which will be different for every environment. The modularity we're providing allows deployers to easily deploy from source, both from a python wheel repo or directly from a git source, and allows the deployer to implement their own tooling around the implementation in order to cater for their custom environment needs.

Looking ahead to Newton’s release in seven months, what significant features do you anticipate OpenStack-Ansible will start/ stop/ continue to develop?

Scalability and Manageability:

Many of our deployers are deploying multiple regions. While this is possible today, it's not simple. We'll be looking to simplify the deployment of multiple regions.

As many of our deployments are medium-large scale, I expect that we'll be revisiting the way we handle our inventory. We need the inventory to scale across regions and we need to implement changes in anticipation of Nova's v2 version of cells.

Interoperability:

We will be refactoring our roles and playbooks to take advantage of the new features provided by Ansible 2. This is expected to improve reliability, predictability and error handling.

Ubuntu 16.04 LTS will release at around the same time as Mitaka. We intend to ensure that the Newton release of OpenStack-Ansible can support a mixed environment of Ubuntu 14.04 LTS and Ubuntu 16.04 LTS in order to allow deployers to transition from the older version to the newer version.

Upgrade Framework:

Notes - https://etherpad.openstack.org/p/OSIC-Roadmap-Measurable-Goals

Documentation:

We're seeing that new contributors need improved documentation to help them get started as a contributor. We'll be putting a lot of effort into bootstrapping new contributors.

Looking ahead one year to the Ocata release, which of the following themes will be most significant in OpenStack Ansible's development? (Themes: Modularity, Manageability, Scalability, Resiliency, Interoperability)

We will continue to improve modularity, managability and scalability as they are key deliverables for OpenStack-Ansible. I expect that we will increase Interoperability with other projects in the Ocata cycle.

4 of 8

Designate

Project Snapshot

OpenStack DNS as a Service

# of Contributors (Mitaka)

# of Companies

(Mitaka)

Mitaka (2 specs & 1 blueprint)

Newton

Ocata

Service consolidation
DNSec
New panels in Horizon

Per tenant DNS servers
Non standard DNS record types
GeoIP support

OpenStack Client support
Refactoring of domains -> zones
Multiple pool support for zones

5 of 8

Rally

Project Snapshot

OpenStack Verification and Benchmarking

# of Contributors (Mitaka)

# of Companies

(Mitaka)

Mitaka (33 specs. Version 0.3.2 )

Newton

Ocata

Export task and verification results
Ramp up load generator
Unified task validation
Graceful shutdown
Nested Atomic Operations

Multi Scenario load generation
Persistent context
Package management for plugins
Rally as a service

Unit test coverage increase
Tempest config generator refactoring
Cleanup after crash
VM workloads framework
API version coverage
Time Series reporting

6 of 8

16 Projects

# of Contributors (Mitaka)

# of Companies

(Mitaka)

120

Mitaka (14 specs )

Newton

Ocata

Gate health tracking board
Testr datastore layering and architecture - complete
Tempest run CLI
Multiple resource configuration

Gate health tracking board (alpha)
Microversion support
Testr datastore layering and architecture - start
Service client plug-in
Neutron support rewrite
Reintegrate tempest-lib
Multinode Grenade
Partial Upgrade (beyond Nova)

Integration Test Suite

(Tempest, Grenade…)

7 of 8

Magnum

Project Snapshot

Containers service

# of Contributors (Mitaka)

# of Companies

(Mitaka)

Mitaka

Newton

Ocata

Neutron integration without additional overlay
Cinder volumes as Magnum data volumes
Operational (Install/User/Troubleshooting) documentation

Enhanced interoperability with other OpenStack services, e.g. Keystone
Modular, pluggable, architecture for custom k8s/swarm/mesos bays or entirely new bay types

CoreOS support introduced for K8S bay type
Highly available bay configuration
Improved functional test coverage

* CoreOS: Supported provisioning a k8s bay (that is a k8s cluster on top of a set of Nova instances) based on CoreOS. In before, Fedora Atomic was the only supported OS. In Mitaka, CoreOS was introduced as an alternative choice. The choice of OS can be specified when users are about to provision the bay.

* HA configuration: Support to configure a bay in an HA manner. In before, HA configuration was only supported in k8s. In Mitaka, we extended the support to Docker Swarm and Apache Mesos. In other words, all the existing bay types support HA deployment right now.

* Functional/Integration test: In Mitaka, we introduced three additional functional test pipelines. The first one leverage Tempest to test the APIs. The second one is for testing the Swarm bay. The third one is for testing the Mesos Bay. With the additional tests, we captured many problems and delivered the fixes in an early stage.

1 of 8

2 of 8

3 of 8

4 of 8

5 of 8

6 of 8

7 of 8

8 of 8