Steps to create a stable release branch

Awesome! We’ve decided as a group to create the next stable branch. Here are some steps to remind you on how to do it.

  1. Go to each repo as a core member and create the branch with the SHA you want, usually you will just branch from master.:

    git checkout master
    git pull
    git checkout -b stable/<release>
    git push gerrit stable/<release>
    
  2. Changes for each cookbook and repo, create a bug to tie all the following branch work together

    1. Update .gitreview to include defaultbranch=stable/<release>

    2. Update Berksfile to reference branch: 'stable/<release>' for each branched cookbook

    3. See https://review.opendev.org/729795 for an example

  3. Create a review with the above and put it up against the stable/<release> branch.

  4. Get it merged in and you should be good

If you think doing this manually for all the cookbooks is a lot of work, these commands might help you automating it (please CHECK the git diff before you actually push something):

  1. First pull all the cookbooks into one folder and then try to run these commands one by one from the root folder (they are intentionally separated, since they will create some changes that you do not want to push).

    for i in -bare-metal -block-storage client -common -compute \
      -dashboard -dns -identity -image -integration-test -network \
      -ops-database -ops-messaging -orchestration -telemetry ; do
      git clone https://opendev.org/openstack/cookbook-openstack${i}
    done
    
  2. Check your sed version and make sure you have at least version 4.2.1 (if you are on OS X you have to install gnu-sed via Homebrew since the one installed does work in mysterious ways).

    export RELEASE=train
    for i in $(ls | grep cookbook) ; do
      cd $i
      git checkout -b stable/${RELEASE}
      sed -i "/opendev/a\ \ branch: 'stable\/${RELEASE}'" Berksfile
      sed -i 's/opendev.*$/&,/' Berksfile
      echo "defaultbranch=stable/${RELEASE}" >> .gitreview
      cd ..
    done
    
    # The next one is important, since there are changes that are wrong
    # and should be corrected manually (like adding the branch:
    # stable/train for a non-openstack cookbook)
    for i in $(ls | grep cookbook) ; do cd $i; git diff; cd .. ; done | less
    
    # After you checked all your changes, you can go ahead, commit it and
    # push it up for review.
    for i in $(ls | grep cookbook) ; do
      cd $i
      git review -s
      git commit -am "stable/${RELEASE} release patch"
      git review
      cd ..
    done
    

Steps for a new master branch

Note

These steps are also useful when making global changes that are dependent on each other.

Now we have a new master, need to get it in sync with matching base OpenStack release.

  1. Possible infra changes for changes to the gates we want for this release.

  2. Decide on new levels of tools (Chef Workstation, Cookstyle, upstream cookbooks), we have always be trying to move forward with these.

  3. Changes for each cookbook and repo:

    1. Update metadata with new major version level

    1. Run cookstyle -a to fix any style issues. Run Cookstyle again and fix any issues that couldn’t be fixed automatically.

    2. Update code with refs to old OpenStack release, i.e. “ocata” -> “pike” (Common release and yum attributes, …).

    3. Update all code looking for deprecation’s that can now be removed.

    4. Update any package dependencies that have changed for each component.

    5. Update all spec test platforms to targeted levels we want for this release.

It will likely be necessary to disable integration jobs from being voting on the openstack-chef repo in order to allow to merge all these changes. If you do so, make sure that you have one patch at the end which depends on all others, this one should be passing all integration jobs again before you merge anything. See this topic as an example.

You will want to do this in the following order and add Depends-On: to each review to it’s dependencies. Everything should depend on the openstack-chef repo since that’s where all of the tests reside and will need to be updated. To simplify, you can chain dependencies based on their metadata.rb dependencies. See below on specifics:

  1. openstack-chef Repo

  2. Common (depends on openstack-chef)

  3. Client (depends on openstack-chef and Common)

  4. Ops-Messaging (depends on openstack-chef)

  5. Ops-Database (depends on openstack-chef)

  6. Identity (depends on Client, Ops-Messaging and Ops-Database)

  7. Image (depends on Identity)

  8. Block-Storage (depends on Image)

  9. Network (depends on Identity)

  10. Compute (depends on Image and Network)

  11. Dns (depends on Network)

  12. Orchestration (depends on Identity)

  13. Telemetry (depends on Identity)

  14. Dashboard (depends on Identity)

  15. Integration-Test (depends on Image and Dns)