How to Contribute to the Mirantis Packages Repository

If you notice incorrect behaviour or some defects while working with Mirantis packages repository that is closed for direct contribution, we encourage you to make an input by reporting a bug and/or sending us a patch with a fix if any.

  1. Make sure you are registered and logged into Launchpad.
  2. Go to https://bugs.launchpad.net/mos where you can view a list of all the MOS open bugs.
  3. In the search field, type the keywords of the bug you are looking for. To simplify your search, you can:
    1. order bugs by your preference (importance, status, number, title);
    2. use a gear button to customize visible bug information by choosing appropriate checkboxes;
    3. use the Tags field at the right of the page to view bugs for a specific component if necessary.
  1. When you find a bug that you want to contribute to, click on its title to see all the details and activity log.
  2. On the bottom of the bug page, find and click the Add attachment or patch link.
  3. On the next page, describe your patch in the field for comments.
  4. Use the Choose File/Browse button to attach your solution. Make sure that the checkbox This attachment contains a solution (patch) for this bug is selected.
  5. Click the Post Comment button to publish your patch on Launchpad.
  6. You can subscribe to the bug and receive email notifications about new comments, or only receive an email when this bug is closed. Use the Edit bug mail link at the right of the bug page to select desired options.
  1. Go to https://bugs.launchpad.net/mos/+filebug and fill in the Summary field. It is going to be the headline for your bug. Please be descriptive but short and to the point. Once done, click Next.
  2. You may see a list of possible bugs that describe a similar or the same issue:
    • To avoid duplicates, make sure there is no bug already filed for the same issue.
    • If the bug already exists in the list, you can update it with new details or attach a patch with a bug fix (see instructions above). 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 “Neutron doesn’t work” that can cover whole ranges of root causes.
    • If your bug doesn’t exist in the list, click the No, I need to report a new bug button.
  3. In the Further information field, list as much details as you can using the following checklist:
    • Environment on which you have found the bug:
      1. Exact MOS version (by copy-pasting the output from http:///api/version). Leave a note if you know that the bug reproduces on other MOS versions.
      2. Operating system
      3. Reference architecture (HA/non-HA)
      4. Network model (Nova-network, Neutron+VLAN, Neutron+GRE, other)
      5. Related projects installed (Sahara, Murano, Ceilometer)
      6. Any other important system details related to the bug
    • Steps to reproduce the bug
      • Describe step-by-step what actions are required for the issue to occur (for the developers’ team to replicate the same bug on their side).
      • Instead of copying and pasting an error from logs, specify, for instance, whether OpenStack crashed or it was just a warning without any consequences (it helps to correctly identify the issue severity).
      • Example:
        1. Create and deploy a cluster – 3 controllers, 1 compute, 1 Сinder (Centos, HA, Neutron GRE, Cinder for volumes).
        2. After a successful deployment, reboot the primary controller.
        3. Wait for half an hour.
        4. Try to create a volume.
    • Actual result (example for the issue above: volume sticks in creation state)
    • Expected result (example for the issue above: volume can be successfully created)
    • Workaround – in case you know how to overcome the problem (example for the issue above: restart Cinder services, force-delete and re-create the affected volumes).
  4. Click Extra options. Here you can attach diagnostic snapshot, screenshots and log files to simplify the fix process for the developers’ team. If you attach a patch with a bug fix, check the box This attachment is a patch under the Choose File/Browse button. Also, please add a description of your patch if any.
  5. If your bug affects security, check the box This bug is a security vulnerability under the Further information field. The security group for Mirantis OpenStack will be notified.
  6. Finally, click the Submit Bug Report button to publish your bug. A ‘Thank you’ notification appears on the page with your newly created bug.
  7. If the bug contains sensitive information about your environment (name, diagnostic snapshot, specific IP addresses, network diagrams, credentials), change the access type to your bug. At the top right of the page, click on the field This report contains Public information (all the bugs are Public by default), and choose Private in the menu.
  8. You can change the settings for email notifications about this bug using the Edit bug mail at the right of the bug page.
WEBINAR
Mirantis and Ericsson on Edge Computing