openstack-ansible-lxc_conta.../CONTRIBUTING.rst
Kevin Carter 0c16334a2c
updated for lxc-container-create for multi-distro support
This change updates the lxc-container-create role to build lxc containers
using the download template. The build supports ubuntu 14.04/16.04 and
RedHat/CentOS 7 using the multi-distro framework.

This change is incorporating updates built into the lxc_hosts role. Once
merged this should unblock all work geared toward multi-distro support and
testing. The testing structure has been updated to match what is being done
in other roles.

A new file was created "manual-tests.rc" which assists in manual testing
by exporting the needed environment variables to run the role tests without
requiring everything to run through tox which has undesirable side-effects
when running tests that span multiple roles.

Change-Id: Iee304dd026e0865e0444259d2132122233d90f5f
Depends-On: Ie13be2322d28178760481c59805101d6aeef4f36
Co-Authored-By: Jesse Pretorius <jesse.pretorius@rackspace.co.uk>
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2016-05-03 15:15:34 -05:00

3.0 KiB
Raw Blame History

OpenStack LXC container create

tags

openstack, lxc, container, cloud, ansible

category

*nix

contributor guidelines

Filing Bugs

Bugs should be filed on Launchpad, not GitHub: "https://bugs.launchpad.net/openstack-ansible"

When submitting a bug, or working on a bug, please ensure the following criteria are met:
  • The description clearly states or describes the original problem or root cause of the problem.
  • Include historical information on how the problem was identified.
  • Any relevant logs are included.
  • The provided information should be totally self-contained. External access to web services/sites should not be needed.
  • Steps to reproduce the problem if possible.

Submitting Code

Changes to the project should be submitted for review via the Gerrit tool, following the workflow documented at: "http://docs.openstack.org/infra/manual/developers.html#development-workflow"

Pull requests submitted through GitHub will be ignored and closed without regard.

Extra

Tags:

If it's a bug that needs fixing in a branch in addition to Master, add a '<release>-backport-potential' tag (eg juno-backport-potential). There are predefined tags that will autocomplete.

Status:

Please leave this alone, it should be New till someone triages the issue.

Importance:

Should only be touched if it is a Blocker/Gating issue. If it is, please set to High, and only use Critical if you have found a bug that can take down whole infrastructures.

Style guide

When creating tasks and other roles for use in Ansible please create them using the YAML dictionary format.

Example YAML dictionary format:
- name: The name of the tasks
  module_name:
    thing1: "some-stuff"
    thing2: "some-other-stuff"
  tags:
    - some-tag
    - some-other-tag
Example NOT in YAML dictionary format:
- name: The name of the tasks
  module_name: thing1="some-stuff" thing2="some-other-stuff"
  tags:
    - some-tag
    - some-other-tag

Usage of the ">" and "|" operators should be limited to Ansible conditionals and command modules such as the ansible shell module.

Issues

When submitting or working on an issue, please ensure the following criteria are met:
  • The description clearly states or describes the original problem or root cause of the problem.
  • Include historical information on how the problem was identified.
  • Include any relevant logs.
  • If the issue is a bug that needs fixing in a branch other than Master, add the backport potential tag TO THE ISSUE (not the PR).
  • The provided information should be totally self-contained. External access to web services/sites should not be needed.
  • If the issue is needed for a hotfix release, add the 'expedite' label.
  • Steps to reproduce the problem if possible.