Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add metadata to policy textual representation #121

Open
bluikko opened this issue Jul 6, 2023 · 0 comments
Open

Add metadata to policy textual representation #121

bluikko opened this issue Jul 6, 2023 · 0 comments

Comments

@bluikko
Copy link
Contributor

bluikko commented Jul 6, 2023

This is yet another operator-quality-of-life small feature request:

The route server policy textual representation file could have simple metadata in it, preferably (IMHO) in a non-visible way such as some specific HTML tag (in head? not sure if suitable ones exist, maybe no?) or simply as a HTML comment.

Suggested metadata:

  • Date when the policy file was generated.
  • And possibly, more contentious metadata:
    • Version of arouteserver that generated this HTML file. Specifically I want to mention that currently this file is completely "whitelabel" in that it does not mention "arouteserver" and staying neutral would be good. If version is added, especially together with product name, this feature would be lost so adding this should be thought out carefully.
    • Changed timestamp of source file(s) used for generation of this file, such as the arouteserver configuration file. Not sure if this is useful since there might be many files and it'd just be more work. It might help in some obscure troubleshooting but I personally do not see the use for it.

Personally I'd be fine with just the generation timestamp.

This metadata could help in pinpointing specific versions of the policy. Users may have these cached or lying around for whatever -- usually bad -- reasons.

It might affect automated workflows where the policy files are compared for whatever reason as that metadata would change often.
I could not say if such use cases exist in the real world and this change would probably be net-beneficial to operators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant