gilded forge
What kind of tests or plans do you use when you are in the planning of moving from a major to major release?
In my role, we call this a Full Certification whereas moving from P release to another in the same version is a Light Certification.
We use a ton of NFS, SMB, Multi Protocol as well as many many replication relationships.
RBAC is always challenging, as well as the multiple configurations of the svms.
Just looking to get an idea of the steps other people are using.
dawn venture
Anybody that has been NetApp'ing for a while will always tell you wait for at least a P2 release at a minimum, and P4 release conservatively. Assuming your devices are using AutoSupport, you can use the Upgrade Advisor tool online in Active IQ to look for upgrade issues and impacts. In a perfect world, your block based protocols are configured for multiple paths and there will be no impact on HA failover during upgrade. NFS will resume as well as Continuously Available SMBv3 Shares (Only supported for Hyper-V and SQL Server clusters). SMBv1, SMBv2, and non-Continuously Available SMBv3 sessions will be dropped on HA failover, so upgrade outside of business hours. You want to update your disk qualification package, disk firmware, shelf firmware, BIOS, and Baseboard Management Controller (BMC or Service Processor) and verifying that the version is compatible with both the starting and upgrading to version of ONTAP in the support matrix of each update. Versions of some of these updates are included in ONTAP releases, however they may not be the latest versions or you may be so far behind and need to stair-step up.
dusky laurel
Don't forget to check interoperability with all the different software which has some sort of ONTAP integration. Check "security login show" to see which users exists (at least I really hope you use a different user for each application).
Checking "application-record show" might help but not all NetApp software is integrated there.
If you are conservative use this KB to decide on the version: https://kb.netapp.com/Support_Bulletins/Customer_Bulletins/SU2
Does not mean that later P-releases are less stable but the mentioned version is the minimum recommended one:
"This guidance is not intended to preclude the use of later available Service Updates but serves to provide a baseline below which NetApp would not actively recommend deployment without additional scrutiny."
deft edge
We have rarely waited for P2/P4, I look at what bugs are fixed and if any of them are impacting us or new things will be something we are going to use mostly.
But, yes, generally it's P4 to do a push to production systems and P2 or P3 for dev/qa beforehand.
gilded forge
my question was more around what you do to certify that the version you are installing is ready for your work environment.
deft edge
we have a dedicated staging environment we install on and test. if it has no issues and no systems come back with any kind of errors/problems after 4 weeks, we install in our production environment
gilded forge
We do that kind of thing too, but do you have a process defined for vetting out all the features work the same or better than they did before? For example command line options are sometimes deprecated or changed. Or there is new option available under say nfs options that wasn't there before.
deft edge
if there are any significant changes in the platform, yes.
Otherwise it's just a basic set of 'plumbing' tests that our product group runs to ensure our stuff works properly end to end.
If there are changes, we hold pushing to production for at least 2 months, until new/depcrated features are validated
security audit, pen test, etc are all ran against major changes
gilded forge
Ok for a Major, we have like 100's of steps that we follow to ensure the version is going to behave like before so that we are not caught off-guard when a new feature or setting\option is added\removed. It's a cumbersome process and I hate it. I am looking for better ways to do this kind of stuff.
deft edge
automation testing with something like ansible, puppet, chef, etc.
fluid surge
Usually, we test it on test and little production environment, then after a week or two rollout to most of our customers if it's a critical update.
fluid surge
Ok for a Major, we have like 100's of steps that we follow to ensure the version...
100 steps seems wild and a overkill, but in a industry like banking/finance it can be a standard... Can you share the list, just out of curiosity.
You can try to automate some steps and in the end generate an report to keep an eye on, instead of following all the steps manually.