The content below is taken from the original (Announcing a new cloud provider for OpenStack’s CI system: OVH), to continue reading please visit the site. Remember to respect the Author & Copyright.

The OpenStack Project Infrastructure Team has added OpenStack Compute instances from OVH to the project’s continuous integration system.

There are a lot of ways to participate in an Open Source community like the OpenStack project and OVH is doing so in a way that best matches their strengths: contributing cloud resources to the project to drive our test and automation systems — resources which are critical to ongoing development.

OpenStack runs up to 30,000 automated jobs each day to test proposed changes and build documentation and software artifacts. The system responsible for this is itself a large multi-cloud application. It utilizes OpenStack Compute instances from Rackspace, HP Cloud, and now OVH to provide this service to developers. Each of those instances runs a single job and is then deleted in order to ensure the next job starts with a clean slate. This puts an extraordinarily high demand on our providers.

We are very excited by the addition of OVH, not only because it will help us scale to meet the needs of a growing project, but also because it demonstrates one of OpenStack’s key features: cross-cloud compatibility. When a developer uploads a proposed change to an OpenStack project, available instances from any of our contributing cloud providers will be used interchangeably to test it.

We are able to do this with the help of a number of OpenStack projects. First, we create a base image to use on all of our providers using Diskimage-builder. This ensures that all of our tests operate in an identical environment. Our test resource manager, Nodepool, uses the shade library to upload each of these images to our providers using the OpenStack Image service. Each of our providers is configured slightly differently, but shade handles the details so that Nodepool can focus on the business logic. Nodepool then identifies demand from our automation system, Zuul, to create OpenStack Compute instances as needed.

The Infrastructure Team thanks OVH for their contribution as well as our existing cloud providers, and we are excited about sharing our experience using this very demanding OpenStack application with all of them.

The content below is taken from the original (Technical Committee Highlights November 27, 2015), to continue reading please visit the site. Remember to respect the Author & Copyright.

Welcome back from Tokyo. While there, I did not realize a three-dimensional subway map exists for Tokyo, but I sure loved traveling on the subway.

Welcoming the latest projects to OpenStack

Speaking of amazing cities and their subway maps, we should mention the growing list of OpenStack projects. We welcome these projects to OpenStack governance since the OpenStack Summit.

• Monitoring – both OpenStack and its resources: monasca
• Backups for file systems using OpenStack: freezer
• Deployment for OpenStack: fuel
• Cluster management service for Compute and Orchestration: senlin
• Integrate Hyper-V, Windows and related components into OpenStack: winstackers

During these last weeks, the TC also had other project reviews requests that were put on hold for later once those projects and/or teams are more mature and ready to join the Big Tent.

Reports from TC Working Groups

Project Team Guide

The Project Team Guide team held a session back in Tokyo to discuss the next steps for this project. As a result of that session, more content will be created (or moved from the wiki): add community best practices, detail the benefits and trade-offs of the various release models, introduce deliverables and tags (as maintained in the governance repo’s projects.yaml), detail what common infrastructure projects can build on, and so on.

Communications Group

The communications working group (the one that brings these blog posts to you) will continue to operate under the same model. Announcements, summaries and communications will be sent out as they have been during the last cycle. Remember that feedback is always welcome and the group is looking for ways to improve. Talk back to us, we’re listening!

Project Tags

These are the latest new project tags created by the Technical Committee.

• team:single-vendor: A new tag was added to communicate when a project team is currently driven by a single organization. We had some discussion about using the term “vendor” or “organization” but this intent is to show the opposite of a diversity in the team’s makeup.
• assert:supports-upgrade: A new tag has been added to communicate when a project supports upgrades. Teams should apply this tag to their project if they assert they intend to support ongoing upgrades.
• assert:supports-rolling-upgrade: A new tag has been added to communicate when a project supports rolling upgrades. Team should apply this tag to their project if they assert that operators can expect to perform rolling upgrades of their project, where the service can remain running while the upgrade is performed.

The content below is taken from the original (OpenStack Developer Mailing List Digest November 21-27), to continue reading please visit the site. Remember to respect the Author & Copyright.

Success Bot Says

• vkmc: We got 7 new interns for the Outreachy program December-March 2015 round.
• bauzas: Reno in place for Nova release notes.
• AJaeger: We now have Japanese Install Guides published for Liberty [1].
• robcresswell: Horizon had a bug day! We made good progress on categorizing new bugs and removing old ones, with many members of the community stepping up to help.
• AJaeger: The OpenStack Architecture Design Guide has been converted to RST [2].
• AJaeger: The Virtual Machine Image guide has been converted to RST [3].
• Ajaeger: Japanese Networking Guide is published as draft [4].
• Tell us yours via IRC with a message “#success [insert success]”.

Release countdown for week R-18, Nov 30 – Dec 4

• All projects following the cycle-with-milestones release model should be preparing for the milestone tag.
• Release Actions:
  • All deliverables must have Reno configured before adding a Mitaka-1 milestone tag.
  • Use openstack/releases repository to manage the Mitaka-1 milestone tags.
  • One time change, we will be simplifying how we specify the versions for projects by moving to only using tags instead of the version entry for setup.cfg.
• Stable release actions: Review stable/liberty branches for patches that have landed since the last release and determine if your deliverables need new tags.
• Important dates:
  • Deadline for requesting a Mitaka-1 milestone tag: December 3rd
  • Mitaka-2: Jan 19-21
  • Mitaka release schedule [5]

Common OpenStack ‘Third-Party’ CI Solution – DONE!

• Ramy Asselin who has been spearheading the work for a common third-party CI solution announces things being done!
  • This solution uses the same tools and scripts as the upstream Jenkins CI solution.
  • The documentation for setting up a 3rd party ci system on 2 VMs (1 private that runs the CI jobs, and 1 public that hosts the log files) is now available here [6] or [7].
  • There a number of companies today using this solution for their third party CI needs.

Process Change For Closing Bugs When Patches Merge

• Today when a patch merges with ‘Closes-Bug’ in the commit message, that marks the associated bug as ‘Fix Committed’ to indicated fixed, but not in the release yet.
• The release team uses automated tools to mark bugs from ‘Fix Committed’ to ‘Fix Released’, but they’re not reliable due to Launchpad issues.
• Proposal for automated tools to improve reliability: Patches with ‘Closes-Bug’ in the commit message to have the bug status mark the associated bug as ‘Fix Released’ instead of ‘Fix Committed’.
• Doug would like to have this be in effect next week.

Move From Active Distrusting Model to Trusting Model

• Morgan Fainberg writes most projects have a distrusting policy that prevents the following scenario:
  • Employee from Company A writes code
  • Other Employee from Company A reviews code
  • Third Employee from Company A reviews and approves code.
• Proposal for a trusting model:
  • Code reviews still need 2x Core Reviewers (no change)
  • Code can be developed by a member of the same company as both core reviewers (and approvers).
  • If the trust that is being given via this new policy is violated, the code can [if needed], be reverted (we are using git here) and the actors in question can lose core status (PTL discretion) and the policy can be changed back to the “distrustful” model described above.
• Dolph Mathews provides scenarios where the “distrusting” model either did or would have helped:
  • Employee is reprimanded by management for not positively reviewing & approving a coworkers patch.
  • A team of employees is pressured to land a feature with as fast as possible. Minimal community involvement means a faster path to “merged,” right?
  • A large group of reviewers from the author’s organization repeatedly throwing *many* careless +1s at a single patch. (These happened to not be cores, but it’s a related organizational behavior taken to an extreme.)

Stable Team PTL Nominations Are Open

• As discussed [8][9] of setting up a standalone stable maintenance team, we’ll be organizing PTL elections over the coming weeks.
• Stable team’s mission:
  • Define and enforce the common stable branch policy
  • Educate and accompany projects as they use stable branches
  • Keep CI working on stable branches
  • Mentoring/growing the stable maintenance team
  • Create and improve stable tooling/automation
• Anyone who successfully contributed to a stable branch back port over the last year can vote in the stable PTL election.
• If interested, reply to thread with your self-nomination.
• Deadline is 23:59 UTC Monday, November 30.
• Election will be the week after.
• Current candidates:
  • Matt Riedmann [10]
  • Erno Kuvaja [11]

Using Reno For Libraries

• Libraries have two audiences for release notes:
  • Developers consuming the library.
  • Deployers pushing out new versions of the libraries.
• To separate the notes from the two audiences and avoid doing manually something that we have been doing automatically, we can use Reno for just deployer release notes.
• Library repositories that need Reno should have it configured like service projects, with separate jobs and a publishing location different from their developer documentation [12]

Releases VS Development Cycle

• Thierry writes that as more projects enter the Big Tent, there have recently been questions about release models and development cycle.
• Some projects want to be independent of the common release cycle and dates, but still keep some adherence to the development cycle. Examples:
  • Gnocchi wants to be completely independent of the common development cycle, but still maintain stable branches.
  • Fuel traditionally makes their releases a few months behind the OpenStack release to integration all the functionality there.
• All projects above should current be release:independent, until they are able to (and willing) to coordinate their own releases with the projects following the common release cycle.
• The release team currently supports 3 models:
  • release:cycle-with-milestones is the traditional Nova model with one release at the end of a 6-month dev cycle and a stable branch derived from that.
  • release:cycle-with-intermediary is the traditional Swift model, with releases as-needed during the 6-month development cycle, and a stable branch created from the last release in the cycle.
  • release:independent, for projects that don’t follow the release cycle at all.
    • Can make a release supporting the Mitaka release (including stable updates).
      • Can call the branch stable/mitaka even after the Mitaka release cycle, as long as the branch is stable and not development.
    • Should clearly document that their release is *compatible with* the OpenStack Mitaka release, rather than *part of* the Mitaka release.