[AAA-109] When it is known some features have not activated fully, do not return 401 Created: 21/Sep/16 Updated: 21/Mar/19 Resolved: 14/Sep/17 |
|
| Status: | Resolved |
| Project: | aaa |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Vratko Polak | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 6772 |
| Description |
|
Typical case is in High Availability testing. One cluster member has been rebooted and it is starting again. Not every AAA bundle is ready, so restconf returns 401. In reality, the user probably is allowed to access the resource, so 401 may be misleading. Restconf could wait until AAA is ready (or a timeout expires). Setting severity to minor, as this only happens shortly after boot, and it may not be easy to figure out when exactly AAA becomes ready. It is possible that AAA project has authority on HTTP processing at this stage, in which case this is a AAA Improvement. |
| Comments |
| Comment by Jakub Toth [ 23/Sep/16 ] |
|
It is how you mentioned. This should be in AAA project. |
| Comment by Vratko Polak [ 10/Mar/17 ] |
|
Still present (Carbon snapshot). There are more specific Bugs (soon to be) open, differing on reason of why a feature is not activated yet. |
| Comment by Ryan Goulding [ 01/May/17 ] |
|
This might be resolved now due to 8214; a service was exposed and NETCONF (RESTCONF really) now consumes the service. Have you seen this recently, or can we close this? |