OpenStack is a fast moving open source project and rapidly adding new features. It is actually very impressive how they have so many interrelated projects (one or more for every sub-system lets call it 60) and still manage to coordinate regular testing and releases every six months. This is of course, primarily, designed for running virtual machines in “cattle mode” = lots of them, they are all the same and if one gets sick then shot it in the head and make another one.
PowerVC then takes the official newly released OpenStack code, adds all their good features that us Power people want and the Power hardware and control (HMC / PowerKVM) connections. Retest and Release all in a couple of weeks. They also create a very simple update process that just takes a couple of minutes. This makes our OpenStack via PowerVC life very simple compared to a OpenStack upgrade.
I find each new PowerVC realise has some “wow!!” factor in new features – I have been regularly very impressed. In fact, it is a good week when I get the new code drop, update and go exploring what new “goodies” they have delivered each time and this is 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 really good features twice a year that I/you want to use for increased flexibility, finer control or offering a better service to our customers/users groups.
This twice a year, massive update means we should rethink our update policies!
I have a number of customers that want to use PowerVC but start off doing it “old school” using “old thinking” i.e. using N-1 and updates every other year (or not at all).
- First mistake is installing the N-1 version for risk aversion reasons.
Then 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 proto-type 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 just installed the 8 month old version rather than the 1 month old version then start 2 months familiarisation before rolling out to operations. By the time it goes live they will be 1 year and two releases out of date. IMHO this is [rude word deleted] “sub-optimal”.
- 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 you will more than likely benefit from the many new features. I get customers that definitely what the new features. Request they get them early 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 i.e. what we put in now has to work unchanged for 2 years.
Neither of these are good thinking for rapidly advancing software being delivered twice a year with massive new functions
– and the upgrades are simple, effect just one machine and take a few minutes.
What do I recommend:
- Install and Start on a current release.
Always start on the current PowerVC release and if the new release is two months away – stretch your testing time to make sure you upgrade before going production use.
- Be prepared to upgrade every 6 months.
Grab a copy of the GA code – try it for a month on parallel hardware and then backup and update.
You probably already have two PowerVC installations – one being your warm standby with the last backup on board from the master in use PowerVC machine. This stand-by machine is ready to recover the backup file and take-over, if you ever have an unrepairable problem with your master PowerVC installation.
It might not be obvious but you can have two PowerVC’s running in parallel connected to the same set of HMC’s and their dependant Power Servers and connected to the same storage providers. Not I would NOT recommend using them equally – one should be your master machine and they will NOT communicate with each other or share information. They are independent. So you can have a second PowerVC with newer release and run some tests – I would recommend the test machine only operates on particular machines any thing is creates should be removed or adopted by the master PowerVC before you decommission the test PowerVC.
New PowerVC release testing
- Install the newly GA PowerVC version on a fresh Red Hat OS.
- Then go discover the same HMC’s, Power servers and storage.
- This lets you check the connectivity and hardware support is as expected.
- Then you can go try the new features to see how you can benefit from them.
- Do some regression testing like deploying your standard image to build confidence before updating the “master” PowerVC.
- Decommission the test PowerVC = remove test items you created or if you now want it get the master PowerVC to adopt it (like Manage Existing Virtual Machine or Manage Existing – disk volume).
- Then on the master perform a PowerVC data backup, OS level backup and a disk snapshot so you have plenty of quick recovery options.
- Upgrade your production PowerVC(s).
Bottom line: Please keep PowerVC up to date
– or your missing out on all the new fun stuff that can save you time plus adds flexibility.
Well, as always, these are my opinions.
Feel free to comment and disagree or voice different ideas in the comments below.
Cheers, Nigel Griffiths
The post PowerVC – Please Stay Current with Twice a Year Updates is fed from ReadySpace Cloud Services United States. Contents strictly belongs to ReadySpace and its respective partners.