Browse Source
These documents borrow from the cinder, nova and ironic guides put together painstakingly by numerous developers. Change-Id: Ida3480fd1b9cab8eeb9ad002cce7200d89e01cb6 Story: #2007236 Task: #38535 Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>changes/24/720324/4
Goutham Pacha Ravi
2 years ago
5 changed files with 500 additions and 23 deletions
@ -1,19 +1,23 @@
|
||||
If you would like to contribute to the development of OpenStack, |
||||
you must follow the steps in this page: |
||||
The source repository for this project can be found at: |
||||
|
||||
http://docs.openstack.org/infra/manual/developers.html |
||||
https://opendev.org/openstack/manila |
||||
|
||||
Once those steps have been completed, changes to OpenStack |
||||
should be submitted for review via the Gerrit tool, following |
||||
the workflow documented at: |
||||
This repository is mirrored to GitHub at: |
||||
|
||||
http://docs.openstack.org/infra/manual/developers.html#development-workflow |
||||
https://github.com/openstack/manila |
||||
|
||||
Pull requests submitted through GitHub will be ignored. |
||||
Pull requests submitted through GitHub are not monitored. |
||||
|
||||
Bugs should be filed on Launchpad, not GitHub: |
||||
To start contributing to OpenStack, follow the steps in the contribution guide |
||||
to set up and use Gerrit: |
||||
|
||||
https://bugs.launchpad.net/manila |
||||
https://docs.openstack.org/contributors/code-and-documentation/quick-start.html |
||||
|
||||
Bugs should be filed on Launchpad: |
||||
|
||||
https://bugs.launchpad.net/manila |
||||
|
||||
For more specific information about contributing to this repository, see the |
||||
Manila contributor guide: |
||||
|
||||
https://docs.openstack.org/manila/latest/contributor/contributing.html |
||||
|
||||
@ -0,0 +1,270 @@
|
||||
============================ |
||||
So You Want to Contribute... |
||||
============================ |
||||
|
||||
For general information on contributing to OpenStack, check out the |
||||
`contributor guide <https://docs.openstack.org/contributors/>`_ to get started. |
||||
It covers all the basics that are common to all OpenStack projects: the |
||||
accounts you need, the basics of interacting with our Gerrit review system, |
||||
how we communicate as a community, etc. |
||||
|
||||
Below will cover the more project specific information you need to get started |
||||
with Manila (Shared File System service). |
||||
|
||||
|
||||
Where is the code? |
||||
~~~~~~~~~~~~~~~~~~ |
||||
|
||||
manila |
||||
| The OpenStack Shared File System Service |
||||
| code: https://opendev.org/openstack/manila |
||||
| docs: https://docs.openstack.org/manila/ |
||||
| api-ref: https://docs.openstack.org/api-ref/shared-file-system |
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc |
||||
| Launchpad: https://launchpad.net/manila |
||||
|
||||
|
||||
python-manilaclient |
||||
| Python client library for the OpenStack Shared File System Service API; |
||||
includes standalone CLI shells and OpenStack client plugin and shell |
||||
| code: https://opendev.org/openstack/python-manilaclient |
||||
| docs: https://docs.openstack.org/python-manilaclient |
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary |
||||
| Launchpad: https://launchpad.net/python-manilaclient |
||||
|
||||
|
||||
manila-ui |
||||
| OpenStack dashboard plugin for the Shared File System Service |
||||
| code: https://opendev.org/openstack/manila-ui |
||||
| docs: https://docs.openstack.org/manila-ui |
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary |
||||
| Launchpad: https://launchpad.net/manila-ui |
||||
|
||||
|
||||
manila-tempest-plugin |
||||
| An OpenStack test integration (tempest) plugin containing API and |
||||
scenario tests for the Shared File System Service |
||||
| code: https://opendev.org/openstack/manila-tempest-plugin |
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-automatic |
||||
| Launchpad: https://launchpad.net/manila |
||||
|
||||
|
||||
manila-image-elements |
||||
| A Disk Image Builder project with scripts to build a bootable Linux |
||||
image for testing and use by some Shared File System Service storage |
||||
drivers including the Generic Driver |
||||
| code: https://opendev.org/openstack/manila-tempest-plugin |
||||
| release model: no releases |
||||
| Launchpad: https://launchpad.net/manila |
||||
|
||||
|
||||
manila-test-image |
||||
| A project with scripts to create a Buildroot based image to create a |
||||
small bootable Linux image, primarily for the purposes of testing Manila |
||||
| code: https://opendev.org/openstack/manila-image-elements |
||||
| images: https://tarballs.opendev.org/openstack/manila-image-elements/ |
||||
| release model: no releases |
||||
| Launchpad: https://launchpad.net/manila-image-elements |
||||
|
||||
|
||||
manila-specs |
||||
| Design Specifications for the Shared File System service |
||||
| code: https://opendev.org/openstack/manila-specs |
||||
| release model: no releases |
||||
| Launchpad: https://launchpad.net/manila |
||||
|
||||
|
||||
See the ``CONTRIBUTING.rst`` file in each code repository for more |
||||
information about contributing to that specific deliverable. Additionally, |
||||
you should look over the docs links above; most components have helpful |
||||
developer information specific to that deliverable. |
||||
|
||||
Manila and its associated projects follow a coordinated release alongside |
||||
other OpenStack projects. Development cycles are code named. See the |
||||
`OpenStack Releases website`_ for names and schedules of the current, past |
||||
and future development cycles. |
||||
|
||||
|
||||
Communication |
||||
~~~~~~~~~~~~~ |
||||
|
||||
IRC |
||||
--- |
||||
|
||||
The team uses `IRC <https://docs.openstack.org/contributors/common/irc.html>`_ |
||||
extensively for communication and coordination of project activities. The |
||||
IRC channel is ``#openstack-manila`` on Freenode. Contributors work in various |
||||
timezones across the world; so many of them run IRC Bouncers and appear to be |
||||
always online. If you ping someone, or raise a question on the IRC channel, |
||||
someone will get back to you when they are back on their computer. |
||||
Additionally, the IRC channel is logged, so if you ask a question |
||||
when no one is around, you can `check the log |
||||
<http://eavesdrop.openstack.org/irclogs/%23openstack-manila/>`_ |
||||
to see if it has been answered. |
||||
|
||||
|
||||
Team Meetings |
||||
------------- |
||||
We host a one-hour IRC based community meeting every Thursday at 1500 |
||||
UTC on ``#openstack-meeting-alt`` channel. See the `OpenStack meetings page |
||||
<http://eavesdrop.openstack.org/#Manila_Team_Meeting>`_ for the most |
||||
up-to-date meeting information and for downloading the ICS file to integrate |
||||
this slot with your calendar. The community meeting is a good opportunity to |
||||
gather the attention of multiple contributors synchronously. If you wish to |
||||
do so, add a meeting topic along with your IRC nick to the |
||||
`Meeting agenda <https://wiki.openstack.org/wiki/Manila/Meetings>`_. |
||||
|
||||
Mailing List |
||||
------------ |
||||
|
||||
In addition to IRC, the team uses the `OpenStack Discuss Mailing List`_ |
||||
for development discussions. This list is meant for communication |
||||
about all things developing OpenStack; so we also use this list to engage with |
||||
contributors across projects, and make any release cycle announcements. |
||||
Since it is a wide distribution list, the use of subject line tags is |
||||
encouraged to make sure you reach the right people. Prefix the |
||||
subject line with ``[manila]`` when sending email that concern Manila on |
||||
this list. |
||||
|
||||
|
||||
Other Communication Avenues |
||||
--------------------------- |
||||
|
||||
Contributors gather at least once per release at the `OpenDev Project Team |
||||
Gathering <https://www.openstack.org/ptg>`_ to discuss plans for an upcoming |
||||
development cycle. This is usually where developers pool ideas and |
||||
brainstorm features and bug fixes. We have had both virtual, and in-person |
||||
Project Technical Gathering events in the past. Before every such event, we |
||||
gather opinions from the community via IRC Meetings and the Mailing list on |
||||
planning these Project Technical Gatherings. |
||||
|
||||
We make extensive use of `Etherpads <https://etherpad.opendev.org>`_. You can |
||||
find some of them that the team used in the past `in the project Wiki |
||||
<https://wiki.openstack.org/wiki/Manila/Etherpads>`_. To share code |
||||
snippets or logs, we use `PasteBin <http://paste.openstack.org>`_. |
||||
|
||||
.. _contacting-the-core-team: |
||||
|
||||
Contacting the Core Team |
||||
~~~~~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
When you contribute patches, your change will need to be approved by one or |
||||
more `maintainers (collectively known as the "Core Team") |
||||
<https://wiki.openstack.org/wiki/Manila#People>`_. |
||||
|
||||
We're always looking for more maintainers! If you're looking to help |
||||
maintain Manila, express your interest to the existing core team. We have |
||||
mentored many individuals for one or more development cycles and added them to |
||||
the core team. |
||||
|
||||
Any new core reviewer needs to be nominated to the team by an existing core |
||||
reviewer by making a proposal on `OpenStack Discuss Mailing List`_. Other |
||||
maintainers and contributors can then express their approval or disapproval |
||||
by responding to the proposal. If there is a decision, the project team lead |
||||
will add the concerned individual to the core reviewers team. An example |
||||
proposal is `here. |
||||
<http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012677.html>`_ |
||||
|
||||
|
||||
New Feature Planning |
||||
~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
If you'd like to propose a new feature, do so by `creating a blueprint |
||||
on Launchpad. <https://blueprints.launchpad.net/manila>`_ For significant |
||||
changes we might require a design specification. |
||||
|
||||
Feature changes that need a specification include: |
||||
-------------------------------------------------- |
||||
|
||||
- Adding new API methods |
||||
- Substantially modifying the behavior of existing API methods |
||||
- Adding a new database resource or modifying existing resources |
||||
- Modifying a share back end driver interface, thereby affecting all share |
||||
back end drivers |
||||
|
||||
What doesn't need a design specification: |
||||
----------------------------------------- |
||||
|
||||
- Making trivial (backwards compatible) changes to the behavior of an |
||||
existing API method. Examples include adding a new field to the response |
||||
schema of an existing method, or introducing a new query parameter. See |
||||
:doc:`api_microversion_dev` on how Manila APIs are versioned. |
||||
- Adding new share back end drivers or modifying share drivers, without |
||||
affecting the share back end driver interface |
||||
- Adding or changing tests |
||||
|
||||
After filing a blueprint, if you're in doubt whether to create a design |
||||
specification, contact the maintainers. |
||||
|
||||
Design specifications are tracked in the `Manila |
||||
Specifications <https://opendev.org/openstack/manila-specs>`_ repository and |
||||
are published on the `OpenStack Project Specifications website. |
||||
<https://specs.openstack.org/openstack/manila-specs/>`_ Refer to the |
||||
`specification template |
||||
<https://specs.openstack.org/openstack/manila-specs/specs/template.html>`_ |
||||
to structure your design spec. |
||||
|
||||
Specifications and new features have deadlines. Usually, specifications for |
||||
an upcoming release are frozen midway into the release development |
||||
cycle. To determine the exact deadlines, see the published release calendars |
||||
by navigating to the specific release from the `OpenStack releases website`_. |
||||
|
||||
|
||||
Task Tracking |
||||
~~~~~~~~~~~~~ |
||||
|
||||
- We track our bugs in Launchpad: |
||||
|
||||
https://bugs.launchpad.net/manila |
||||
|
||||
If you're looking for some smaller, easier work item to pick up and get |
||||
started on, search for the 'low-hanging-fruit' tag |
||||
|
||||
- We track future features as blueprints on Launchpad: |
||||
|
||||
https://blueprints.launchpad.net/manila |
||||
|
||||
- Unimplemented specifications are tracked here: |
||||
|
||||
https://specs.openstack.org/openstack/manila-specs/#unimplemented-specs |
||||
|
||||
These specifications need a new owner. If you're interested to pick them |
||||
up and drive them to completion, you can update the corresponding blueprint |
||||
and get in touch with the project maintainers for help |
||||
|
||||
|
||||
Reporting a Bug |
||||
~~~~~~~~~~~~~~~ |
||||
|
||||
You found an issue and want to make sure we are aware of it? You can do so on |
||||
`Launchpad <https://bugs.launchpad.net/manila>`_. |
||||
|
||||
Getting Your Patch Merged |
||||
~~~~~~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
When you submit your change through Gerrit, a number of automated Continuous |
||||
Integration tests are run on your change. A change must receive a +1 vote |
||||
from the `OpenStack CI system <https://zuul.opendev.org/t/openstack/status>`_ |
||||
in order for it to be merge-worthy. If these tests are failing and you can't |
||||
determine why, contact the maintainers. |
||||
|
||||
See the :doc:`manila-review-policy` to understand our code review |
||||
conventions. Generally, reviewers look at new code submissions pro-actively; |
||||
if you do not have sufficient attention to your change, or are looking for |
||||
help, do not hesitate to jump into the team's IRC channel, or bring our |
||||
attention to your issue during a community meeting. The core team would |
||||
prefer to have an open discussion instead of a one-on-one/private chat. |
||||
|
||||
|
||||
Project Team Lead Duties |
||||
~~~~~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
A `project team lead <https://docs.openstack.org/project-team-guide/ptl.html>`_ |
||||
is elected from the project contributors each cycle. Manila Project specific |
||||
responsibilities for a lead are listed in the :doc:`project-team-lead`. |
||||
|
||||
|
||||
.. _OpenStack Releases website: <https://releases.openstack.org> |
||||
.. _OpenStack Discuss Mailing List: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss |
||||
.. _Manila Project Team Lead guide: ../project-team-lead.rst |
||||
.. _API Microversions: ../api_microversion_dev.rst |
||||
@ -0,0 +1,205 @@
|
||||
.. |
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may |
||||
not use this file except in compliance with the License. You may obtain |
||||
a copy of the License at |
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0 |
||||
|
||||
Unless required by applicable law or agreed to in writing, software |
||||
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT |
||||
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the |
||||
License for the specific language governing permissions and limitations |
||||
under the License. |
||||
|
||||
Manila Project Team Lead guide |
||||
============================== |
||||
|
||||
A `project team lead <https://docs.openstack.org/project-team-guide/ptl.html>`_ |
||||
for Manila is elected from the project contributors. A candidate for PTL |
||||
needn't be a core reviewer on the team, but, must be a contributor, |
||||
and be familiar with the project to lead the project through |
||||
its release process. If you would like to be a core reviewer begin by |
||||
:ref:`contacting-the-core-team`. All the responsibilities below help us in |
||||
maintaining the project. A project team lead can perform any of these or |
||||
delegate tasks to other contributors. |
||||
|
||||
General Responsibilities |
||||
------------------------ |
||||
|
||||
* Ensure manila meetings have a chair |
||||
|
||||
* https://opendev.org/opendev/irc-meetings/src/branch/master/meetings/manila-team-meeting.yaml |
||||
|
||||
* Update the team people wiki |
||||
|
||||
* https://wiki.openstack.org/wiki/Manila#People |
||||
|
||||
|
||||
Release cycle activities |
||||
------------------------ |
||||
|
||||
* Get acquainted with the release schedule and set Project specific |
||||
milestones in the `OpenStack Releases repository |
||||
<https://opendev.org/openstack/releases>`_ |
||||
|
||||
* Example: https://releases.openstack.org/victoria/schedule.html |
||||
|
||||
* Ensure the Manila `Cross Project Liaisons |
||||
<https://wiki.openstack.org/wiki/CrossProjectLiaisons>`_ are aware of |
||||
their duties and are plugged into the respective areas |
||||
|
||||
* Acknowledge `community wide cycle goals |
||||
<https://governance.openstack.org/tc/goals/#community-goals>`_ and find |
||||
leaders and coordinate with the goal liaisons |
||||
|
||||
* Plan team activities such as: |
||||
|
||||
* ``Documentation day/s`` to groom documentation bugs and re-write |
||||
release cycle docs |
||||
* ``Bug Triage day/s`` to ensure the bug backlog is well groomed |
||||
* ``Bug Squash day/s`` to close bugs |
||||
* ``Collaborative Review meeting/s`` to perform a high-touch review of a code |
||||
submission over a synchronous call |
||||
|
||||
* Milestone driven work: |
||||
|
||||
* ``Milestone-1``: |
||||
|
||||
- Request a release for the python-manilaclient and manila-ui |
||||
- Retarget any bugs whose fixes missed Milestone-1 |
||||
|
||||
* ``Milestone-2``: |
||||
|
||||
- Retarget any bugs whose fixes missed Milestone-2 |
||||
- Create a review priority etherpad and share it with the community |
||||
and have reviewers sign up |
||||
|
||||
* ``Milestone-3``: |
||||
|
||||
- Groom the release notes for python-manilaclient and add a 'prelude' |
||||
section describing the most important changes in the release |
||||
- Request a final cycle release for python-manilaclient |
||||
- Retarget any bugs whose fixes missed Milestone-3 |
||||
- Grant/Deny any Feature Freeze Exception Requests |
||||
- Update task trackers for Community Wide Goals |
||||
- Write the cycle-highlights in marketing-friendly sentences |
||||
and propose to the openstack/releases repo. Usually based on reno |
||||
prelude but made more readable and friendly |
||||
|
||||
* Example: https://review.opendev.org/717801/ |
||||
|
||||
- Create the launchpad series and milestones for the next cycle in |
||||
manila, python-manilaclient and manila-ui. Examples: |
||||
|
||||
* manila: https://launchpad.net/manila/ussuri |
||||
* python-manilaclient: https://launchpad.net/python-manilaclient/ussuri |
||||
* manila-ui: https://launchpad.net/manila-ui/ussuri |
||||
|
||||
* ``Before RC-1``: |
||||
|
||||
- Groom the release notes for manila-ui and add a 'prelude' |
||||
section describing the most important changes in the release |
||||
- Request a final cycle release for manila-ui |
||||
- Groom the release notes for manila, add a 'prelude' section |
||||
describing the most important changes in the release |
||||
- Mark bugs as {release}-rc-potential bugs in launchpad, ensure they |
||||
are targeted and addressed by RC |
||||
|
||||
* ``RC-1``: |
||||
|
||||
- Request a RC-1 release for manila |
||||
- Request a final cycle tagged release for manila-tempest-plugin |
||||
- Ensure all blueprints for the release have been marked "Implemented" |
||||
or are re-targeted |
||||
|
||||
* ``After RC-1``: |
||||
|
||||
- Close the currently active series on Launchpad for manila, |
||||
python-manilaclient and manila-ui and set the "Development Focus" |
||||
to the next release. Alternatively, you can switch this on the |
||||
series page by setting the next release to “active development” |
||||
- Set the last series status in each of these projects to “current |
||||
stable branch release” |
||||
- Set the previous release's series status to “supported” |
||||
- Move any Unimplemented specs in `the specs repo |
||||
<https://opendev.org/openstack/manila-specs>`_ to "Unimplemented" |
||||
- Create a new specs directory in the specs repo for the next |
||||
cycle so people can start proposing new specs |
||||
|
||||
* You should NOT plan to have more than one RC. RC2 should only happen |
||||
if there was a mistake and something was missed for RC-1, or a new regression |
||||
was discovered |
||||
|
||||
* Periodically during the release: |
||||
|
||||
* ``Every Week``: |
||||
|
||||
- Coordinate the weekly Community Meeting agenda |
||||
- Coordinate with the Bug Czar and ensure bugs are properly triaged |
||||
- Check whether any bug-fixes must be back-ported to older stable |
||||
releases |
||||
|
||||
* ``Every 3 weeks``: |
||||
|
||||
- Ensure stable branch releases are proposed in case there are any |
||||
release worthy changes. If there are only documentation or CI/test |
||||
related fixes, no release for that branch is necessary |
||||
|
||||
* To request a release of any manila deliverable: |
||||
|
||||
* ``git checkout {branch-to-release-from}`` |
||||
|
||||
* ``git log --no-merges {last tag}..`` |
||||
|
||||
* Examine commits that will go into the release and use it to decide |
||||
whether the release is a major, minor, or revision bump according to |
||||
semver |
||||
|
||||
* Then, propose the release with version according to semver x.y.z |
||||
|
||||
* X - backward-incompatible changes |
||||
|
||||
* Y - features |
||||
|
||||
* Z - bug fixes |
||||
|
||||
* Use the ``new-release`` command to generate the release |
||||
|
||||
* https://releases.openstack.org/reference/using.html#using-new-release-command |
||||
|
||||
|
||||
Project Team Gathering |
||||
---------------------- |
||||
|
||||
* Create etherpads for PTG planning, cycle retrospective and PTG discussions |
||||
and announce the Planning etherpad to the community members via the Manila |
||||
community meeting as well as the `OpenStack Discuss Mailing List` |
||||
|
||||
* `Example PTG Planning Etherpad <https://etherpad.opendev.org/p/manila-shanghai-ptg-planning>`_ |
||||
* `Example Retrospective Etherpad <https://etherpad.opendev.org/p/manila-stein-retrospective>`_ |
||||
* `Example PTG Discussions Etherpad <https://etherpad.opendev.org/p/manila-ptg-train>`_ |
||||
|
||||
* If the PTG is a physical event, gather an estimate of attendees and |
||||
request the OpenDev Foundation staff for appropriate meeting space. Ensure |
||||
the sessions are remote attendee friendly. Coordinate A/V logistics |
||||
|
||||
* Set discussion schedule and find an owner to run each proposed discussion at |
||||
the PTG |
||||
|
||||
* All sessions must be recorded, nominate note takers for each discussion |
||||
|
||||
* Sign up for group photo at the PTG (if applicable) |
||||
|
||||
* After the event, send PTG session summaries and the meeting recording to the |
||||
`OpenStack Discuss Mailing List` |
||||
|
||||
Summit |
||||
------ |
||||
|
||||
* Prepare the project update presentation. Enlist help of others |
||||
|
||||
* Prepare the on-boarding session materials. Enlist help of others |
||||
|
||||
|
||||
.. _OpenStack Discuss Mailing List: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss |
||||
.. _contacting the core team: contributing#contacting-the-core-team |
||||
Loading…
Reference in new issue