Yes, this happens to us as well. We have two clusters of two each 7220s, running 8.10.0.11 . AP failure for an hour when a controller comes back up is new with 8.10.0.10
We have had an ongoing issue since January (and a TAC case since then) which requires frequent boots of one of the pair of controllers (not always the same one, and not always the same cluster) so we noticed this change in behavior, and I documented it in our TAC case, but they have not addressed it at all. (Since it is not our primary issue, I have not really pushed on it.)
If you go to CLI and run "sh ap database | inc Tot" to get the AP count, and "sh ap database status down" to see down APs on the two members, you find an interesting result: the MD that was in the cluster all along will just drop APs from its database ! They are not down, they are just gone!
We start with a cluster of two MDs, with 570 APs, all up on both MDs (though having lossy pings to one of them. We reboot this problem MD. Here is a timeline of the AP status after giving the reload command:
NO APs are lost while one MD is down -- since they all have tunnels to both MDs, they seamlessly change to the remaining MD.
The problems begin after the booted MD comes back up and rejoins the cluster. At that point, when it has rebooted and is again accepting APs, then we will have a bunch of airwave alerts, and the MM shows a bunch of APs as down.
At about 15 minutes after the reload of the problem MD, the good MD had lost 13 APs from its database. They were not down, it still had 0 APs down, but its total had changed from 570 to 557!
About 30 minutes after one MD was restarted, the MM showed 73 APs down! (Shutting down an MD was totally hitless, but having one start up kills APs for many minutes.) The MD that stayed up has only 514 APs in its database, down from the actual 570. Meanwhile, the newly booted MD has 551 (which is closer to the real total) but it shows 45 as down.
10 minutes later, the MD that stayed up is down to 495 APs in its database. It is unclear why having and MD rejoin the cluster would cause APs to be removed from the active database. (Seems like a bug!)
10 minutes later (50 minutes past reboot) APs are recovering in batches. MM shows only 32 down.
5 minutes later (55 past reboot) only 25 down on MM. Then it shifted to 24 a minute later.
It held at 24 APs down for the next 15 minutes.
Then went to 13 down at 1 hour 20 minutes past reboot, then 6 down a couple minutes later.
Finally, 1 hour 25 minutes after I rebooted one MD, the MM finally showed all APs as up again.
Not sure if anyone from TAC looks at these discussions, but this certainly seems like a big change for the worse from 8.10.0.9 to 8.10.0.10 and 8.10.0.11 !
------------------------------
Steve Bohrer
IT Infrastructure, Emerson College
------------------------------