2017-09-21 08:05 AM
Just upgraded an OCUM 7.1 system (the VMware appliance platform) to version 7.2P1.
The upgrade completed apparently successfully and I see that we have a lot more features in the Web UI now, which is great.
The new OCUM version appears to be running and polling successfully e.g. "Dashboards / Cluster View" and "Configuration / Cluster Sources" show good status info. for all 18 clusters.
However, some of the other pages simply don't respond at all. For example clicking on the "Reports", "Events" or "Configuration -> Alerting" links on the LHS menu just results in the "waiting" spinner apparently endlessly, well, spinning ...
Is this expected? Could it be that the system is simply busy collecting additional data and that these other pages will become available once this completes? Seems unlikely, it has been running for a couple of hours since the upgrade.
FYI, I'm using IE11 as a browser. Based on previous experiences I tried cleaning out the cache and cookie entries related to this hostname, but that doesn't seem to have resulted in any improvement.
Looking forward to your suggestions!
2017-09-21 08:42 AM
We did the same thing with our OCUM 7.1, but we were running on a Windows 2012R2 server. Anyway, while we were attempting to import all the OCPM data from the OCPM 7.1 vApp, the system was a bit sluggish and we saw a few rendering problems. We ended up giving up on the import and just let the old performance data "disappear" with the old vApp.
Can you see how the 7.2 vApp is perfoming on your vSphere console? I don't recall if the vCPU/mem requirements went up with the consolidated 7.2 vApp or not, but you can see if the instance is paging badly, thrashing its vCPUs, etc. Our OCPM 7.1 vApp used to mis-behave a lot which is part of the reason why we ended up just rolling out a full-server verson when we went 7.2 - we'd have gaps in our performance gathering and couldn't determine if it was due to performance issues, network hiccups, or what... Our 7.2 Windows Server environment has been spot-on since implementation and other than a couple caching/cookie issues (similar to what you reference below) we haven't had any issues.
Definitely check what's going on with the vApp first - maybe it's resource constrained (which might be temporary or permanent depending on what's going on).
2017-09-25 01:29 AM
As it turns out, in this case at least, the issue is with the browser on the client side.
I was able to use the Firefox developer version as a test/debug tool. Using that browser (version 56.0b3) the OCUM Web interface doesn't exhibit any of the problems mentioned above - all of those pages are useable.
It appears as if the standard browser package installed on clients here, Internet Explorer 11, is not compatible with some features of the OCUM Web server/JS/UI.
This could a problem in some enterprise deployments where normal users may not easily be able to install an alternative browser, but instead are restricted to the pre-installed package, which is highly likely to be some version of IE for most Windows clients.
2017-09-25 05:48 AM
Good to know - thanks for posting an update!
I've done the "browser-hop" a few times myself with NetApp tools - Chrome seems to work the most consistently for the OnCommand tools, but I have to use FF for anything related to file uploads/etc on the support site.
2017-10-12 12:48 PM
I had the same sort of issue with Firefox (my preferred browser) right after we upgraded our RHEL UM to 7.2P1. After I cleared the browser cache the issue disappeared and it's worked well ever since.