Use separate HTML tables for input/output annotations

[nmittler]

We currently have a single annotation (status) that is generated by the istio runtime. It would be helpful to separate it from the set of configuration annotations, which are set by the user.

[ ] Configuration Infrastructure [x] Docs [ ] Installation [ ] Networking [ ] Performance and Scalability [ ] Policies and Telemetry [ ] Security [ ] Test and Release [ ] User Experience

Expected behavior

Steps to reproduce the bug

Version (include the output of istioctl version --remote and kubectl version)

How was Istio installed?

Environment where bug was observed (cloud vendor, OS, etc)

[nmittler]

@nrjpoddar @louiscryan since we only have a single annotation (status) that is generated from the runtime, do we really think this is necessary? Maybe having a single table with the source (config vs runtime) is sufficient?

We may choose to divide things up into separate tables but I'm not sure that "source" is the right dimension. It might be better to separate out deprecated annotations, for example.

WDYT?

[nrjpoddar]

From a UX point of view having another column where 99% of the time the value is the same won’t get any attention. I still think creating two separate tables is more clear specially if we plan on adding more runtime annotations in the future.

[nmittler]

But do we expect to add more runtime annotations? My concern is that we'll have a second table of one for the foreseeable future.

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2020-11-11. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.