OpenStack is a fast moving open source project and rapidly adding new features 

It is impressive how they have so many interrelated projects (one or more for every subsystem lets call it 60) and still manage to coordinate regular testing and releases every six months.  This project designed for running virtual machines in "cattle mode" = lots of them. The VMs are all treated the same and if one gets sick then it is shot it in the head and you make replacement one.

As each OpenStack version is release, the PowerVC team then:

• Takes the official release code.
• Add the Power hardware support and control of the HMC, VIOS, or OpenPOWER KVM. 
• Adds all the good features that us Power people demand to make available the fine controls of Power computers.
• They retest and release PowerVC in a couple of weeks.
• Then, create or update a simple update process that just takes a couple of minutes. 
• So our OpenStack on Power is simple compared to a raw OpenStack upgrade.

I find each new PowerVC release has some "Wow!" factor in new features.  Each new release is impressive.  In fact, it is a good week when I get the new code drop, update, and go exploring the new "goodies" that are delivered with each time and it happens twice a year.  Most of the other software, I get is updated either once in 18 months or 2 years.  But PowerVC delivers a dozen good features twice a year that we want to use for increased flexibility, finer control or offering a better service to our customers and users groups.

The twice a year, massive update means we need to rethink our update policies!

I have a number of customers that want to use PowerVC but start off updating it "old school" and "old thinking".  For example, reluctant upgrades with an "N -1" policy to update every other year or not at all!

• First mistake is installing the N-1 version for risk aversion reasons.
  Then, start issuing complaints and PMRs because features are missing. Many of these features are in the current release and we get in to "Can IBM emergency back port the feature?"  The answer is "NO GUYS" upgrade your prototype test machine to the current release.  If IBM did spend man-months back porting, then the customer would still have to upgrade to activate them.  So why not upgrade to the current version that would be less work (for IBM) and less risky (for the customers and IBM support)!  I have a customer that installed the 8 month old version rather than the 1 month old version then start 2 months familiarization then go in to production use.  By the time it goes live the PowerVC software is 1 year and two releases out of date.  IMHO it is "suboptimal" that is politely saying it is crazy.
• Second mistake is not being willing to upgrade soon after the next version is released. 
  OK, you might not want to be the first to upgrade to that fresh new release announce today (that would be my job :-).  But IBM clients can benefit from the many new features.  I have customers that definitely want the new features. Request they get them months early (we try not to laugh) but then state categorically, that they cannot upgrade in a couple of months at or near GA.  They are working on what I call the Araldite upgrade policy, that is, what we put in production now and to work unchanged for 2 years.

Neither approach is good thinking for rapidly advancing software being delivered twice a year with many new functions.

The upgrades are simple, affect one virtual machine, and take a few minutes.  The easy upgrade is the prime "value add" provided by IBM.

What do I recommend?

• Install and Start on a current release.
  Always start on the current PowerVC release.  If the new release is two months away, then before entering production use, stretch your testing time and upgrade.
• Be prepared to upgrade every 6 months.
  Grab a copy of the GA code - try it for a month on parallel testing hardware and then backup and update the production system.

You probably already have two PowerVC installations - one being your warm standby with the last backup on board from the primary "in use" PowerVC server. This stand-by machine is ready to recover the latest backup file and take-over, if you ever have an unrepairable problem with your primary PowerVC installation.

It might not be obvious but you can have two PowerVCs running in parallel connected to the same set of Hardware Management Consoles and their dependent Power servers and connected to the same storage providers.  Not I would NOT recommend concurrent use - one must be your primary PowerVC.  Two PowerVC installations do NOT communicate with each other or share information.  You can have a second PowerVC with newer release and run some tests - I would recommend the test PowerVC operates on particular servers and virtual machines.  Anything it creates must be removed or adopted by the primary PowerVC before you decommission the test PowerVC.

New PowerVC release testing

1. Install the newly GA PowerVC version on a fresh Red Hat RHEL7 or Ubuntu 18.04.
2. Discover the same HMCs, Power servers, and storage.
3. Check the connectivity and hardware support is as expected. 
4. Try the new features to learn how you can benefit from them.
5. Then, regression testing like deploying your standard OS image to build confidence
6. Once it passes your tests, update the "primary " PowerVC, as follows.
7. Decommission the test PowerVC = remove test items you created or if you now want it get the primary PowerVC to adopt it (like Manage Existing Virtual Machine or Manage Existing - disk volume).
8. On the primary , perform a PowerVC:
   • Data backup,
   • Operating system backup and
   • Disk snapshots so you have plenty of quick recovery options.
9. Upgrade your production PowerVC.
10. Retest.

Keep PowerVC up to date - or you are postponing all the
new "fun stuff" that can save you both time and flexibility.