#NIMBLE SOFTWARE UPDATE#
#NIMBLE SOFTWARE UPGRADE#
#NIMBLE SOFTWARE CODE#

You may designate these systems to be candidates for running GA Candidate – which we fully support for production use, but don’t recommend them for mission critical workloads. Here, you’re happy for doing the non-disruptive upgrades when needed, and you want access to the latest features. You then may also have a couple of other Nimble systems which are running your general purpose VMs and workloads.

#NIMBLE SOFTWARE CODE#

Therefore, your systems would most likely be a good candidate to be running LTSR code – which is ultimately as close to watertight as you can get, with a 2 year support cycle. You want to ensure that the systems are always available – and aren’t willing to trade off availability whatsoever. You many have a couple of Nimble systems which are dedicated for a mission critical application, such as ticketing, or healthcare needs. (I’ll go into the release process in more detail in another blog).īack to the purpose of this blog: It’s now possible for you, as the Infosight administrator, to designate which criteria of NimbleOS release cycles you want to have made available to each of your systems.

#NIMBLE SOFTWARE UPGRADE#

It’s often common for new features and functionality to be available in a software release which is still running as GA Candidate – and customers that wish to obtain that new feature are asked if they want to upgrade to make it available. Typically, there won’t be any further maintenance releases, and the code will be supported for 2 years until EOL. Software is now designated for long term support for ultra-conservative customers.

Software release has met the designated field availability criteria and requirements, and is recommended for production use.

Not recommended for Mission Critical production use.

Software release has received Maintenance updates from IPR release – and is ready for production use, but similar to IPR – has not met field availability criteria.

GAC Candidate (General Availability Candidate).

Software release is ready for production use, but not met field availability criteria.

Denylist = system is pinpointed to hit bug Y1 or Y2 should they upgrade to Y, and thus the release is disallowed on this system.Īlongside allowlist & denylists being maintained for each release to ensure customer protection, Nimble Support & Infosight also tightly control the rollout and availability for every NimbleOS release by iterating the code through different milestones of availability – again to protect customers:.

Allowlist = system has been validated and is deemed safe to upgrade to release X – no known problems could be exposed.

This article and all future articles now reference the new terminology.īased on the information heartbeated from every system, Infosight presents the right options for upgrades… but most importantly this process & upgrade recommendations is a 100% customised process delivered per system – as every system is completely different. NB: HPE Nimble Storage is deprecating the terms whitelist/blacklist and moving towards a new naming terminology called Allowlist & denylist. This is the concept of using Predictive Analytics and AI-Ops in order to guide individual systems to their own customised yet correct upgrade path in order to mitigate known or problematic bugs. If you’re already a Nimble customer, you’ve probably heard of the terms “whitelisting” and “blacklisting”.

#NIMBLE SOFTWARE UPDATE#

A new feature has just been rolled out into HPE Infosight for Nimble customers and is now live in the portal for everyone to consume – specifically around Nimble software updates, and self-servicing preferences for NimbleOS release cycles & update requirements.