Jump to: navigation, search

Fuel/How to contribute

Join the Fuel team

First steps

Read the Developer's Guide and learn how to setup the accounts and git.

Clone the repositories:

You can search gerrit for all reviews related to Fuel, or use the gerrit dashboard for Fuel for a prioritized list of open reviews (this URL was generated using Gerrit dashboard generator, you need to be logged into Gerrit for it to work).

Please note that OpenStack Infra uses strict checks on your git commit messages. The most important rules are:

  • Keep your commit title short (<80 symbols). It must not end with dot.
  • Body of commit message should be separated from title by one empty line
  • If patch closes bug, then it must have in a body "Closes-Bug: #12345", where 12345 is your LP bug number
  • If patch relates to bug, but doesn't completely solve an issue, then you must use "Related-Bug: #12345"

See the Git commit messages wiki page for more details.

How and where to get help

Subscribe to mailing lists

  • OpenStack developers mailing list. If you are hacking on Fuel, or have technical question about Fuel internals, you are very welcome in this ML with subject containing "[Fuel]".
  • OpenStack users mailing list. Fuel traffic is there with subject containing "[Fuel]". You are welcome to ask questions related to Fuel usage, including errors, etc.
  • OpenStack announcements mailing list. Announcements about the OpenStack project like product release information, security advisories, important discussions. This is a low-traffic, read-only list.
  • There are even more mailing lists out there, visit MailingLists to see the other OpenStack related lists.

IRC at freenode.net

  • The general Fuel channel is called #fuel, and it is logged here.
  • The Fuel development channel is called #fuel-dev, and it is logged here.
  • Development channels for major Fuel components: #fuel-library, #fuel-python, #fuel-ui, #fuel-qa, #fuel-infra.
  • Gerrit notifications for all Fuel repositories: #fuel-tracker.

Quick reference dev links


Contributing

Fuel is large project within which Programming, Linux and Networking intersect. It is written in Python, Ruby and JavaScript. It also has a number of build scripts in bash & make. Documentation is written in Sphinx. New contributors are always welcome.

Fuel library for puppet manifests

Working with puppet upstream modules in fuel-library

If you are going to add a new fork of upstream module - please don't do. Instead, follow the upstream module's contribution rules and provide this module as an additional plug-able component for Fuel. This can be done as a part of plug-able architecture and distributed as a package. Note, if upstream module doesn't fit your requirements, you should first adapt the module for your needs upstream or, for emergency cases, provide custom patch-sets as a part of module as a Fuel plugin distribution.

Modules with licenses incompatible with Apache 2.0 (GPL, etc.) will not be accepted. *Please pay attention to the license information.*

Case A. Adding a new upstream module

If a new puppet module needs to be consumed, the module should be added via the Puppetfile as documented on the Fuel/Library and Upstream Modules page. You should follow the New Module workflow

Case B. Working with existing upstream module via Puppetfile

If a new puppet module needs to be consumed, the module should be added via the Puppetfile as documented on the Fuel/Library and Upstream Modules page. You should follow either the Updating Existing Module or Custom Upstream Module Changes workflow. Ideally, all upstream changes should be done upstream first and a simple Puppetfile update can be used to pull them into fuel-library.

Case C. Working with existing upstream module

If a change needs to be made to an existing upstream module that has not yet been moved to the librarian-puppet-simple workflow then the workflow that should be follow is:

1. Create a review request with a unmodified copy of the upstream module from whichever point you are working from and no other related modifications.

  • This review should also contain the commit hash from the upstream repo in the commit message.
  • The review should be evaluated to determine its suitability and either rejected (for licensing, code quality, outdated version requested) or accepted without requiring modifications.
  • The review should not include code that calls this new module.

2. Any changes necessary to make it work with Fuel should then be proposed as a dependent change(s).

Contributing to existing fuel-library modules

As developers of Puppet modules, we tend to collaborate with the Puppet OpenStack community. As a result, we contribute to upstream modules all of the improvements, fixes and customizations we make to improve Fuel as well. That implies that every contributor must follow Puppet DSL basics, puppet-openstack dev docs and Puppet rspec tests requirements.

The most common and general rule is that upstream modules should be modified only when bugfixes and improvements could benefit everyone in the community. And appropriate patch should be proposed to the upstream project prior to Fuel project.

In other cases (like applying some very specific custom logic or settings) contributor should submit patches to openstack::* classes

Fuel library includes custom modules as well as ones forked from upstream sources. Note that Modulefile (or metadata.json), if any exists, should be used in order to recognize either given module is forked upstream one or not. In case there is no Modulefile in module’s directory, the contributor may submit a patch directly to this module in Fuel library. Otherwise, he or she should submit patch to upstream module first, and once merged or +2 recieved from a core reviewer, the patch should be backported to Fuel library as well. Note that the patch submitted for Fuel library should contain in commit message the upstream commit SHA or link to github pull-request (if the module is not on stackforge) or Change-Id of gerrit patch.

Fuel development environments

VirtualBox

The quickest way to get started with Fuel is to set up an environment under VirtualBox. This is a great way start testing, for instance by using the nightly builds to try to verify, confirm or triage bugs. A quick-start script and instructions can be found at https://software.mirantis.com/quick-start/.

Fuel ISO-build and development environment

Setting up an environment to build the Fuel ISO will allow you to easily build against specific commits in order to do more complicated bug test/confirm/triage/fix work, or augmenting Fuel with new features. In addition to preparing the environment for ISO building, the steps necessary to prepare a dev environment for the other Fuel components (nailgun, astute and doc building) can be found there. Instructions for preparing the environment can be found at http://docs.mirantis.com/fuel-dev/develop/env.html.

Fuel DevOps environment

Setting up a Linux machine as a Fuel DevOps environment will allow you to automate the build/verify/test process, in addition to building the ISO and doing other Fuel-related development. Using libvirt, the devops environment is able to deploy multiple complete OpenStack environments on VMs. Instructions for preparing a devops environment can be found at http://docs.mirantis.com/fuel-dev/devops.html.

Documentation

There are two types of documentation in Fuel: developer and user. Source code for both can be found at fuel-docs repository. The repository uses the reStructuredText format. Documentation is treated as source code, we use the same development process for updating documentation as we do for Fuel code.

Writing documentation

Keeping the Documentation up to date is hard and it is a critical part in every project. Fuel developers use the OpenStack DocImpact process to highlight code changes that need to be reflected in documentation. When a patchset should be documented or requires documentation changes, the reviewer should ask the commiter to add 'DocImpact' tag to their commit message, and makes sure the commit message provides enough information about the impact of the code change. When a commit with a DocImpact tag is merged, a new bug will be automatically created and assigned to the Fuel Documentation team. Technical writers then work with the commiter to reflect the commit in the documentation.

A bug generated from a DocImpact commit should be assigned to fuel-docs team until a technical writer picks it up. Technical writer collects information from the original commit author, and adds it to the right documentation areas. It's commit author's responsibility to provide an informative commit message in the first place, to answer technical writer's questions, and to review documentation commits that address that DocImpact bug.

Update and expand current documentation

Feel free to file bug if you find a problem with the documentation, and provide with a fix for it via same code contribution policy and procedures. There is building documentation page to help with an environment setup for development documentation.

Writing release notes

New features

For every blueprint listed on the milestone page in Launchpad (e.g. https://launchpad.net/fuel/+milestone/5.1), find answers to the following questions:

  • What is the visible impact of the change for a user?
  • Was this previously documented as a Known Issue?

If it is a user visible improvement, add a New Features entry about it. Explain when this feature is important, how it can be enabled, and what are the current expectations and limitations.

If it was a Known Issue before, add a Resolved Issues entry.

Known and Resolved issues

Scan the release milestone page (e.g. fuel 6.0). Review all bugs targeted for the current milestone that satisfy one of the following conditions:

  • "release-notes" tag
  • Critical priority
  • High priority and "customer-found" tag.

Sort the bugs table on the milestone page by Number from highest to lowest, so that you can see when you've reached the bugs that you have already reviewed. If bug status for the current milestone is Fix Committed or Fix Released, consider it for Resolved Issues list. Find answers to:

  • Was this problem present in the previous GA release? (If it was, it will be targeted for at least one previous release series, with target milestone set to a maintenance release in that series.)
  • How does one confirm if their environment is affected? (Identify specific configurations affected by the bug, include error messages or other symptoms that distinguish this bug from others.)
  • If you're affected, how do you recover?
  • What was the root cause and what had to be changed to resolve the issue?

If bug status for the current milestone is Won't Fix and it meets the criteria above, consider it for the Known Issues list. Questions to answer are:

  • How does one confirm if their environment is affected?
  • Is there a workaround? (How do you prevent this problem from affecting you?)
  • What is the recovery procedure?

Reviewing the release notes

Responsibility for every section of release notes is assigned to a technical writer. The writer identifies features and bugs that have to be reflected in their section. For each feature and bug, the writer finds a responsible software engineer: either feature owner, or committer of the most recent bugfix.

If sufficient description (see question lists above) cannot be derived from bug description, blueprint description and specification, and commit messages of related commits, the writer contacts the engineer privately with a request for more information. When a description of a feature or bug is published in a gerrit review, the writer subscribes the engineer to that review, and once again privately sends a request with a link to the documentation review in Gerrit and instructions on how to identify specific documentation files and lines that this engineer must review (e.g. LP bug number, specific RST file, section header or label, etc.)

Fuel engineers must prioritize such information and review requests so that they are able to respond within one week during normal development process, and within one business day during the period between Hard Code Freeze and GA release. Standard escalation process is used when no response to request for information or request for review is received in time. Technical writer is responsible for tracking status of information and review requests and escalations for their section of release notes.

Bugs

Verify bugs

This is very easy to get started, but help here is actually very valuable. Especially when it comes to bugfixes which are relevant to only certain types of hardware. When bugfix is merged, bug is automatically moves to "Fix Committed" status. In Fuel, we set "Fix Released" status for a bug only when it was verified by someone else than a developer. You can simple check out all fix committed bugs and start verifying them. It is required to be in fuel-bugs LP group to be able to change bug status. However you can leave a comment in bug report, and it will be enough for bug supervisors to change bug status. By your request, you can be included into fuel-bugs team to manage bugs yourself.

Test and report bugs

You can always build a developers ISO from master following instructions at http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso. Test different deployment modes, and file bugs. Please do not hesitate to share your findings in IRC for any details you would want to know. Feel free to file bug in a format you want, however it would be great to see a bug in a certain format, with all details in place - to easily reproduce and save a time of developers. You can follow the following simple guidance, which a little bit extend official OpenStack Bugs page.

The bugs you report for Fuel can be either “Public” or “Private”. Private bugs become visible only for Dev, QA, and Support teams. The guidance is as follows:

  • Normally you would want to report a “Public” bug
  • However, if a bug contains any sensitive information, or security vulnerability information, please report a “Private” bug

Before creating a new bug, it's always a good idea to check if a bug like that already exists in the project, and update an existing bug instead of creating something that will later have to be discarded as a duplicate. However, it is important to make sure that both bugs are really related, dealing with a duplicate is much easier than untangling several unrelated lines of investigation mixed into one bug. Do not ever reopen bugs with generic catch-all titles like "Horizon crashed" or "HA doesn't work" that can cover whole ranges of root causes. Do not create new bugs with such titles, either: be as specific about the nature of the problem as you can.

Here is how you file a bug

  • Go to https://launchpad.net/fuel
  • Select “Report a bug” on the right
  • Fill in “Summary” field for a bug. It is going to be the headline. Please be descriptive but short and to the point.
    • Bad - "Sahara doesn’t install"
    • Good - "Sahara fails to install in HA mode when “Neutron with VLANs” network is selected"
  • Enter “Further information”. This is a bug description. It should contain the following sections:
    • Steps to reproduce
      • Bad: Run the deployment in HA configuration
      • Good:
        1. Create a new cluster
        2. Select HA mode, “Neutron with VLANs” for network, and choose to install Sahara
        3. Leave defaults the rest of the settings. Run cluster installation
    • Expected result:
      • Good: Sahara is deployed, up and running.
    • Actual result:
      • Bad: Sahara fails to install.
      • Good: Sahara installation fails with the error message “xxx”. Please see the attached screenshot which shows the errors on “Logs” tab.
    • Workaround
      • Bad: Don’t use “Neutron with VLANs”
      • Good: Switch network mode to “Neutron with GRE” for the deployment to complete successfully.
    • Impact
      • Bad: Needs to be fixed.
      • Good: deployment cannot be completed, because customer requires us to implement a use case for Sahara and “Neutron with VLANs”. Changing configuration to “Neutron with GRE” is not as acceptable option here so this has to be addressed as soon as possible.
    • Description of the environment. Provide enough relevant information:
      • Output of http://fuel-master-node:8000/api/version/
      • Output of shotgun2 report command
      • Operating System
      • Reference Architecture (HA / non-HA)
      • Network model (Nova-network, Neutron+VLAN, Neutron+GRE, etc.)
      • Related Projects installed (Sahara, Murano, Ceilometer)
  • Select visibility for the bug under “This bug contains information that is” field. Either leave it as “Public” (default) or set it to “Private” per the above guidance
  • Add attachments under “Extra Options” section
    • Logs
    • Diagnostic snapshot
    • Screenshots
  • After everything is entered, select the “Submit bug report” button

Confirm and triage bugs

Fuel project uses the same bug management practices as in other OpenStack projects. Please follow Bugs and BugTriage pages.

Triaging the bugs in the Fuel deployment process

When triaging the bugs in the Fuel deployment process (as opposed to bugs in OpenStack components deployed by Fuel), use following additional criteria for bug importance:

  • Critical = can't deploy anything and there's no trivial workaround; data loss; or security vulnerability
  • High = specific hardware, configurations, or components are unusable and there's no workaround; or everything is broken but there's a workaround
  • Medium = specific hardware, configurations, or components are working incorrectly; or is completely unusable but there's a workaround
  • Low = minor feature is broken and can be fixed with a trivial workaround; or a cosmetic defect
  • Wishlist = not a bug, either close as Won't Fix, or associate with a blueprint (create new blueprint if no existing blueprint covers the feature requested in the bug)



Also Fuel uses different meaning for two bug states:

  • Confirmed = somebody who is not submitter looked into the bug and made sure that it is properly triaged. The person must made sure that milestone, importance and assignee are properly set. Still the bug could be not reproduced or confirmed as genuine.
  • Fix Released = somebody who is not assignee verified that the issue does not reproduce after it was fixed. The status is left for QA to mark bugs as verified after they are fixed.
Additional guidelines for User eXperience (UX) issues

In some cases a bug may cause significant impact to UX in these cases we can use additional criteria to set bug priority

  • Critical = Requires massive effort to work around, including un/under-documented commands and edits to config files
  • High = Requires modification of config files, interfaces that users aren't expected to use (ie the API when it's _intended_ to work in the CLI / UI (exclusive of interfaces that are intended to only be available via API) or requires custom node yaml (again except when it should exclusively be available)
  • Medium: Straight forward commands in the CLI
  • Low and Wishlist = as above
Additional guidelines for Infrastructure bugs
  • Critical = at least one team is blocked or delivery of a critical feature is blocked, no workaround
  • High = critical with a workaround, or other infra regression without workaround, or delivery of a high severity feature is blocked
  • Medium = infra regression with workaround, or required for delivery of a medium severity feature
  • Low = infra reliability, reproducibility, or coverage improvement
  • Wishlist = cosmetic infra improvement that doesn't match higher priority UX issue definitions
Additional guidelines for Documentation bugs
  • Critical = following the instructions from documentation can cause outage or data loss
  • High = documentation includes information that is not true, or instructions that yield the advertised outcome
  • Medium = important information is missing from documentation (e.g. new feature description)
  • Low = additional information would improve reader's understanding of a feature
  • Wishlist = cosmetic formatting and grammar issues

Bug Triaging routine

When triaging bugs, please use the following routine:

  1. Review all New bugs.
  2. Assign each New bug to the release series under development (focus of development according to Fuel project timeline) and set corresponding bug status and milestone for that release series.
  3. Consider changing the bug title to be more specific, replace generic statements like "deployment timeout exceeded" with description of the root cause (if identified) or symptops that are unique for that bug.
  4. Consider visibility status of the bug. If it contains sensitive information, set it to Private. If it describes a security vulnerability, set it to Private Security.
  5. If the bug does not contain sufficient information as described in Fuel/How_to_contribute#Test_and_report_bugs, request the missing information, and set the bug status to Incomplete. Add a comment using the following template: We didn't receive required details in order to correctly troubleshoot the problem, so we are setting this bug into Incomplete state. Please provide reqested information and we will investigate this issue further. If you think it was incorrectly set to Incomplete, please comment in the bug.
  6. Add an area tag according to Fuel/Bug_tags#Area_tags list.
  7. Add other applicable tags from the Fuel bug tags taxonomy.
  8. If there is sufficient information on how to reproduce the bug and milestone, importance and assignee are properly set, set the status to Confirmed.
  9. If there is sufficient information to start implementing a fix, set the status to Triaged.
  10. If the root cause of the bug is identified, include it in the bug description.
  11. Review all Incomplete bugs
  12. If an Incomplete bug has new updates, use the same steps as described above for New bugs.
  13. If an Incomplete bug did not have any updates for 4 weeks, close it as Invalid. Add a comment using the following template: This bug was incomplete for more than 4 weeks. We cannot investigate it further so we are setting the status to Invalid. If you think it is not correct, please feel free to provide requested information and reopen the bug, and we will look into it further.
  14. During Code Freeze for a release, review all bugs targeted at that release milestone, make sure it is updated daily by the assignee (or bug reporter if the bug is not assigned to a person).
  15. If you know that the bug is related to some blueprints, link this bug to these blueprints. To do this, go to corresponding blueprints page and hit 'Link a bug report' link.



Remember that every state change of a bug must be accompanied by a comment explaining the reason why the change was made.

Useful LaunchPad searches and tools

Fix bugs

The most simple and easy way to contribute code into Fuel is to start with bug fixes. First of all, check out bugs with "low-hanging-fruit" tag. You can also take any other bug. For easier management of bugs, Fuel uses multiple functional groups, and you will see bugs assigned to fuel-python, fuel-library, fuel-qa and other teams. Feel free to pick any of those. It is assigned to group, so group can get an email notification about a bug. Unless it is reassigned to particular engineer to work on that bug, then it means the bug is not taken by anyone yet, so feel free to take it. Bugs with assignee set to a person are not yet imply that someone works on them (but it should in ideal world). If it is even in "in progress" state, feel free to ping a person and ask if he really works on that bug, and feel free to assign yourself otherwise.

Special flow for bugs with swarm-blocker tag

Bugs with 'swarm-blocker' tag block our nightly tests and should be fixed as soon as possible. Also other developers can be blocked by this kind of bugs. We have two extra requirements for these bugs in order to improve communication, planning, analyse and decrease their income.

Developer who fixes the bug should provide a comment with "ETA: date-of-merge" text with preliminary date of fix delivery for the current release. This information should be provided at the date of bugs assignment and updated with a new comment if needed.

Also developer who fixes the bug should provide a comment with "RCA: root-cause-analysis" text with the description of the reason how this bug appeared. Ideally it should contain the link to the review with regression. Other popular cases are 'new test case' and 'bug in test case'. This information should be provided when available. After that developer should add a tag 'rca-provided'.

Backport bugfixes to stable release series

When you create a new bug with High or Critical priority or upgrade an existing bug, always check if this bug is present in the supported stable release series (at least one most recent stable release). If it is present there, target it to all affected series (even if you don't expect to be able to eventually backport a fix). If it's not present in stable releases, document that on the bug so that other people don't have to re-check.

When you propose a fix for a bug, always start with fixing it in the master branch. If the fix only applies to the stable branch and is not relevant in master, explain that in the commit message. For a bug targeted for stable release series, cherry-pick the fix commit onto the stable/x.x branch for each series it is targeted for, after the fix was merged to master (creating backports prematurely leads to possible inconsistency between master and stable/x.x versions of the same commit). Use the same Change-Id and topic (git review -t bug/<id>) to make it easier to track down all backports for that bug. You can also use "Cherry Pick To" button in Gerrit if the commit can be applied to the stable branch without conflicts. Note, that normally it is up to the author how to manage the Change-Id for a patch, but we insist to keep it the same across all of the related backports.

When you approve a bugfix commit for master branch, use the information available so far on the bug and in the review request to review and maybe update backporting status of the bug. Is its priority high enough to need a backport? Is it targeted to all affected release series? Are there backport commits already? If yes, are they up to date with the commit that was merged to master?

  • For all series where backport should exist and doesn't, create a backport review request yourself.
  • For all other affected series, change bug status to Won't Fix and explain in bug comments.
  • Do not merge commits into stable branches until it was merged into master, unless commit message explicitly documents why it doesn't apply to master.

When you find a bug in a stable release, do not simply target it to the next release in that maintenance release series. Instead, target it to the release designated as "current focus" on the Fuel home page in Launchpad. If it's a High or Critical priority bug, additionally target it to the releases series it was originally found in, and, if applicable, all release series in between.

If a bug is present in a maintenance release and not present in current release series, it should have one of the following statuses in the current release series:

  • Incomplete if root cause analysis is not finished
  • Fix Committed if root cause analysis shows that the bug is fixed by changes merged after the maintenance release the bug was found in
  • Invalid if root cause analysis shows that the bug was introduced by a change specific to this maintenance release series

Enhancements

Propose enhancements

Enhancements for Fuel are proposed using the mechanism of blueprints. The process is very similar to the bugs:

  • Select "Register a Blueprint". Typically, you’ll find this link on the right side of the launchpad page.
    • Enter a Name for the blueprint. If possible, include the name of the sub-component of fuel as the first word of the name (or just fuel for a broader blueprint), then a very short descriptor using dashes between words. For example, ui-declarative-wizard or fuel-stop-deployment.
    • Enter a Title for the blueprint. The title should describe the feature as clearly as possible in up to 70 characters. This title is displayed in every feature list or report.
  • Enter a Summary of the blueprint.
    • Summarize the idea of the blueprint in a user story. If you have an existing user story in a public document, include the link.
    • If a public document isn’t yet created and the user story is extensive, you can use https://etherpad.openstack.org/ to document the full user story. You can use the Name that you used for the blueprint as the Pad name.
  • Propose your blueprint by selecting the milestone in which you plan to complete the blueprint.
  • You won’t need to enter any other fields, so now just choose Register Blueprint.

If you’re just entering a new idea without a design, you can leave the specification URL field blank. If you have a design, here is how you get it published and approved:

  • Upload a design specification in the "specs/<release>" folder in fuel-specs
    • e.g. access-control-master-node
    • it should be based on the template, see the instructions in the template for more details
    • get it reviewed by submitting your patch using Gerrit, in the usual way: Development Workflow
    • at the end of each release, non-completed specs will be removed
    • you need to re-submit for the following release, should the blueprint slip
  • In order to get your spec approved, it usually requires to get +1 from the following folks:
    • All mandatory design reviewers (it's usually people who familiar with the area of the proposed enhancement)
    • Topic expert if any (e.g your enhancement somehow affects Fuel Web UI then you need to get +1 from the Fuel Web UI team)
    • QA
    • For cross-component enhancements, it also requires to have +1 from core of affected components.
  • Once your design specification has been approved and merged into fuel-specs git repo:
    • Update your blueprint's specification URL to point to the design specification in fuel-specs git
    • Note, this should link to git (as in the template link above), not to the gerrit change

When done, drop an email about the new blueprint to the mailing list to attract attention of Fuel developers, who are likely to provide early feedback and request additional information.

Please read OpenStack Blueprints page for detailed definition of blueprints and their lifecycle.

Implement new features

To implement a new feature, you will need to address the following:

  1. File a blueprint, with all required feature details, as described in Propose enhancements section above and on Blueprints page
  2. PTL or core developers of Fuel should approve a blueprint, when all required information is provided.
  3. Please no active contribution unless there is an agreement on design. To get an approval, you can discuss a feature in the mailing list.
  4. Every new feature must not break other features, and whether work fine with features we had before, or be disabled in combination with features which do not work with the new one. Short list of features to check compatibility with:
    • All distributions (currently CentOS & Ubuntu)
    • Networking (nova-network, Neutron)
    • Combination with other roles on a node. For example, MongoDB role should not be placed with Ceph.
    • Disk partitioning (will it use existing partition or new one needs to be created?)
    • Network verification
  5. Other requirements for features:
    • logging of services should be done via rsyslog for Fuel Library contributions
    • implementation should be scalable, or otherwise limitations should be clearly stated in a design doc. It is unacceptable to degrade scalability and performance of already existing features.
  6. Start implementation and propose code changes frequently and by small pieces. This is the only way to successful merge - it is unrealistic to review changesets with 1000+ lines of code.
  7. Every feature should have a set of tests:
    • CasperJS and Selenium tests are for Fuel Web UI
    • Nailgun uses Python Unit Test framework for unit and integration tests
    • Astute uses RSpec for unit and integration tests
    • Consider extending OSTF tests for implemented feature
    • System tests, which use Devops framework, are run against an ISO, i.e. when all components are integrated. System tests last for up to 6-8 hours and run every night. As these tests are ran against integrated environment, their result represents a higher interest. Every large feature which has pieces in more than one Fuel component must be covered by system tests.
    • If feature requires special hardware, or special deployment setup, then existing CI should be extended with such hardware and required changes into devops framework. It should be discussed with the Fuel community in mailing list in order to come up with a joint decision.
  8. Documentation. New features must be well documented in both user and development documentation.
  9. Please propose changes for a feature before feature freeze date. Otherwise, changes won't be even reviewed before code freeze, and we will not let changes to land into master before milestone proposed branch is created. This will allow Fuel team to concentrate on stabilization of the current release, and put all the force into squashing bugs. Rules are similar to core OpenStack projects, see FeatureFreeze and ReleaseCycle.

Bugs with "feature" tag

We have a special Delivery team working on small enhancements to cover gaps in Fuel functionality

It works on bugs with “feature” tag and small stories with estimated duration less than 5 man days

You can track these activities on Enhancements Team Trello Board

Tests

Unit and integration tests for Nailgun

Nailgun uses Python Unit Test framework for unit and integration tests. Help in writing test is highly appreciated - we always want better coverage! Please checkout how to setup development environment for Nailgun tests, and follow How to Test Your Code guidance.

Code review rules

When contributing code changes to Fuel, please use the development workflow and follow Fuel specific rules and recommendations.