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

Added Internal Metadata table #30

Merged
merged 3 commits into from
Jul 29, 2022
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion napps/metadata.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,10 @@ perspective, the napp has to provide APIs to store,
retrieve and manage Metadata information. From the
Kytos core perspective objects like Switch,
Interface and Link have their metadata managed
by the Topology Kytos Napp.
by the Topology Kytos Napp. In addition to this,
sometimes, metadata needs to be used internally and exclusively,
meaning that writes and deletions should only be done the NApp that
viniarck marked this conversation as resolved.
Show resolved Hide resolved
owns this resource, and shouldn't be allowed via APIs.

From a user perspective, you have to make sure
you are using the proper metadata and also
Expand Down Expand Up @@ -55,6 +58,18 @@ Metadata
| priority | topology | link | float | Link's priority, used for traffic engineering | 02.02.2022 | pathfinder |
| delay | topology | link | float | Link's latency in ms | 02.02.2022 | pathfinder |


Internal Metadata
-----------------


| Metadata | Napp | Object | Type | Description | Date | Used by |
|-----------------------|-------------|------------|-------|-----------------------------------------------|------------|-------------------------------|
| liveness_status | topology | link | str | Link's liveness status up\|down | 06.30.22 | topology, core |
| last_status_change | topology | link | float | Link's last status change timestamp | 06.30.22 | topology |
| last_status_is_active | topology | link | bool | Whether Link's last status is active or not | 06.30.22 | topology |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it wouldn't be simple if instead of last_status_is_active we just store last_status (which could also store other values in the future (in maintenance, maybe?) - not sure if it is actually useful).

Copy link
Member Author

@viniarck viniarck Jul 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@italovalcy great idea, I've mapped this enhancement for the next release kytos-ng/topology#99. Also, there's another similar opportunity with last_status_change, currently it stores a float epoch, which works great. But, if it were stored as datetime, especially since it's a metadata value, it would provide a better UX for providers who could be able to read it without conversions, and also on MongoDB its type would be ISODate which would enable queries based on datetime constraints without conversions, I haven't mapped this as an enhancement though, other than documenting on that comment that I linked here. Let me know what you think and if we should map this enhancement too. Appreciated your review and inputs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've mapped it here kytos-ng/topology#104

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@italovalcy thanks for reviewing and the suggestions, once these new two issues are addressed we can update this page again.



Usage examples
--------------

Expand Down