OpenStackCharms

Revision 3 as of 2014-06-02 09:26:37

Clear message

OpenStack Charm Development Process

Overview

The intent of this document is to outline the development process around the set of Juju Charms used to deploy OpenStack on Ubuntu.

Stability in the charms as they become more widely used is critical for users; by defining a policy for developing and release charm updates, stability of the charms should be improved and maintained.

Charm Development Cycle Overview

The OpenStack charms will be managed under a 6 monthly release cycle aligned to Ubuntu’s. During this cycle, feature development and bug fixes will be made against ‘next’ branches, leaving the trunk branches in a stable state. Bug fixes, when appropriate, may be backported to the stable trunk branch under a similar process to the Ubuntu SRU process.

Scope

The following charms fall within the scope of this policy:

  • quantum-gateway
  • nova-cloud-controller
  • nova-compute
  • cinder
  • cinder-ceph
  • glance
  • keystone
  • openstack-dashboard
  • nvp-transport-node
  • ceilometer
  • ceilometer-agent
  • heat
  • nova-vmware
  • neutron-openvswitch-agent
  • neutron

In addition, a charm-helpers (http://launchpad.net/charm-helpers) stable branch will also be made at release to limit the scope for introduction of regressions to stable charms via charm-helper syncs:

  • lp:~openstack-charmers/charm-helpers/stable

All stable charms should reference this branch for syncing.

NOTE: charm-helpers stable branch management may change if/when charm-helpers starts producing releases.

Charm Development Process

Charms should be developed against the /next branches under the openstack-charmers team on Launchpad, for example:

  • lp:~openstack-charmers/charms/trusty/cinder/next

Merges should be proposed against these branches first for all changes.

Three weeks prior to Ubuntu release (post OpenStack and Ubuntu final freeze), these branches will enter a freeze period during which extended testing will take place prior to co-ordinated release with Ubuntu. During this period, only bug fixes will be landed in to the /next branches.

Charm Stable Update Process

Charm users will discover bugs in the OpenStack charms; Fixes for such bugs must be made in the /next branch first. After review and merging into /next, fixes may also be targeted to the stable branch with the following requirements:

  • A bug report must be present for the problem, with appropriate procedure on how to reproduce the bug to support verification testing.
  • The branch should contain the minimal fix for the bug; branches should not included unrelated bug fixes or features.
  • Unit tests and amulet tests should be included to prevent regressions in the future.
  • Small new features may be introduced, so long as they don’t change default configuration and have limited scope for regression of the charm codebase.
  • New unit and amulet tests may also be added to stable branches.

Gating

*WIP*

All proposed changes to OpenStack charms should be verified upon initial approval by a member of the openstack-charmers team. This verification should include:

  • Running unit tests.
  • Running lint to ensure code standards are met.
  • The branch merges into the target branch with no conflicts

Upon successful completion of the above, the following testing should be run:

  • Amulet charm tests.
  • Reference topology tests.

A subsequent approval from one of openstack-charmers after completion of this testing should automatically land the proposed branch into the target branch.