Is there a reason to hide hotfixes in Software Update?

[bgranholm]

I was curious to know if there was some prevailing notion as to why PA would keep the hotfixes hidden or at least not readily available from the Software section of the firewall itself.

It is displayed where deployment without the hotfix is a very bad idea such as 4.1.8.

But for in cases like 4.1.7, where the PA tech informed us that we should absolutely install hotfix2, what is the rationale in not making it available without a call to tech support?

[torm]

Have asked the same question myself several times. Have been told that hotfixes are made do fix one or a few critical bugs, and that support needs to identify that you have that particular problem before making it available to you.

I can't see why it would be a problem to make the hotfix available on the devices, though.

[darren_g]

Because then Palo Alto don't get embarrassed by everyone when a hotfix fixes one bug, and introduces another one!

I just installed 4.1.11-h1 to supposedly fix the high management CPU issue - which it does.

But now I can't sync my config between my HA partners no matter what I try!

Second time in two days I've had to roll back from an "update". Ridiculous.

[mikand]

If anyone from PaloAlto is reading this thread, it would be nice to get some kind of official statement of wtf is going on with the QA process within PaloAlto!?

Or did the QA process get infiltrated by people from PA's competitors (sometimes I get this as a bad feeling, on the other hand MIT tested and verified that alu foil hats doesnt work http://berkeley.intel-research.net/arahimi/helmet/ 😉 ?

[rsouthern]

Hotfixes are created to address a very small number of problems, usually a maximum of 1 or 2 in any given hotfix release.  Those problems requiring a hotfix are usually unique to a small number of customers. In some cases a workaround is available but may not be feasible for that customers specific environment. By releasing the hotfix to only the customers who are confirmed to be having the problem addressed by the fix and are unable to use a workaround(?) (hence the requirement to call TAC), it limits the risk to the overall customer base of encountering new problems in that hotfix release. Palo Alto Networks provides specific guidance or caveats for deploying or testing hotfixes.

All fixes in a hotfix release are made available in the next maintenance release. Each maintenance release goes through the full QA testing cycle. During the testing of the maintenance release, the fixes for the hotfix receive a longer period of testing under a wider range of conditions. Palo Alto Networks has taken the position to make hotfixes available as needed for specific customers and conditions, and, under most circumstances not to make hotfixes generally available to all customers. A very limited number of exceptions to this rule have been made in some cases, which has likely caused some of the confusion.

[ericgearhart]

I know this sounds rather snarky and is offtopic for this particular thread, but to put it delicately I would suggest that PA ought to evolve their current definition of a "full QA testing cycle." From my own personal experience at work and some of the frustration expressed on this forum by other PA customers, there is room for improvement with regards to what is in the scope of what is tested.

[darren_g]

That's a nice, polite corporate line, but I smell male bovine droppings.

I don't mean to be confrontational, but on both occasions where I've needed a hotfix (in my current installation, not counting previous positions), it's been for fairly major issues - the high management CPU with 4.1.11-h1, and from memory a HA synchronisation issue with 4.1.8-h3 - issues, especially in the case of the high management CPU which were/are affecting a *lot* of people, judging by the comments and queries in this forum. Releasing these to general population and posting a broadcast email to subscribers (as is done for maintenance outages etc) would be the best action - then users can choose to apply the hotfix if they're experiencing the issue concerned.

And your comment about thorough QA is patently untrue - if it was, then the issue with the management CPU wouldn't exist across several different releases 9I've seen reports of it from 4.1.11, 5.0.1 & 5.0.2 so far) - or, if it's true, Palo Alto needs to hire some new QA engineers, because the existing ones are falling down on the job - these aren't obscure, little problems - they're issues which are part of the *core* of the system which makes Palo Alto better than, say, Cisco or Checkpoint - and they...are...failing.

Either Palo Alto's definition of a "full QA testing cycle" is different to mine, or it's not being done properly.

OK, maybe I *do* mean to be confrontational. But with what we pay for these boxes compared to other solutions, I expect them to work WITHOUT running into such basic bugs.

[mikand]

I can just agree with what darren.gibbs above is saying (with perhaps slightly more words than my one-liner 😉

Its also interresting how one hotfix obviously is breaking other things aswell.

I mean if a specific hotfix lets say 4.1.11-h1 is about to fix the high mgmt cpu issue, then how come new bugs submerges once h1 is installed which (according to posts on this forum) didnt exist in the 4.1.11 itself?

Another good example that the "full QA testing cycle" is failing big time is the QoS bug. Didnt take long before it was getting reported in this forum... and once PA finally released a new version - it took minutes to identify that the bug WASNT fixed... I can get that QA can sometimes be troublesome, specially when dealing with many operating systems, libraries, versions etc - but in PA case there is a limited set of locked down appliances (PA-200, 500, 2020, 2050, 3020, 3050, 4020, 4050, 5020, 5050, 5060 and then the VM-series) where looking at actual hardware specifications its down to 4-5 various models.

So my question remains... whats up with this "QA process" over at PA nowadays!?

[nextgenhappines]

Instead of releasing a new minor releases every 6 to 8 weeks.   Just QA the software better and fix the problems before release it to the customers based.