-
Notifications
You must be signed in to change notification settings - Fork 4
Roadmap
On the Topic Detail page, add the list of Topic Admins.
On the Application Detail page, add the list of Application Admins.
This information should appear on both the public and private versions of these detail pages.
For each application, add a certificate duration parameter. When the application requests a key pair, the duration would be used to set the duration of the certificate. This will require a new data field in the Application editing modal and Application detail page.
For now, the duration should only be rendered on the private version of the Application detail page.
Create a C++ library for OpenDDS users that acts as a client of the DPM. The client should be able to download security documents, cache them, detect when they need to be renewed, etc.
Create a Java library for OpenDDS users that acts as a client of the DPM. The client should be able to download security documents, cache them, detect when they need to be renewed, etc.
Currently, operators must know something about the internals of the DPM to craft a governance file. The governance file is pulled in during deployment and served as is.
The objective of this task is to allow super admins to define the governance file in the DPM.
The current idea is to store the governance file components in the database and edit them through forms. The tricky part is handling topic names which must agree with the topics themselves. Thus, the Topic Kind may need to be a first-class citizen in the database and it may need to be interpolated into the actual topic names where necessary.
-
To aid in integration, infrastructure providers need status information like which applications are connected. This originates in the RtpsRelay and could be put into a cache and shown in the DDS Permissions Manager. It could be implemented by extending the embedded webserver in the RtpsRelay. It could also be implemented by a separate service that reads the Participant Status topic and makes it available via an HTTP API. It could also be implemented by a separate service that reads the Participant Status topic and pushes the status to the DPM.
-
Some DPM and RtpsRelay operators may need integration between the DPM and the Participant Statistics in the RtpsRelay. This may be necessary for monitoring or billing if the DPM/RtpsRelay is offered as a paid service. The options for implementing this are the same as connectivity monitoring. Displaying the statistics in the DPM would be useful.
-
Operators need the ability to disable individual applications. This information needs to be propagated to the RtpsRelay so it would deny service to the indicated application. This control would be necessary to deal with Member Organizations that are not paying their bill and/or being abusive. An attractive implementation option would be providing an API in the DPM that the RtpsRelay could use for this purpose. Along the same lines, the DDS Permissions Manager could implement OCSP.
-
Implement rate limiting for DPM API.
-
Disable users, applications, and groups
- Cannot authenticate and use the API while disabled.
- Superadmins can enable/disable.
The use of partitions makes the RtpsRelay more efficient to the point that operators may require that each publish/subscribe action must use at least one partition.
An open question is how the partition strings would be validated. That is, what if the partition is the wildcard partition?
The data stored in the DPM is relational. Grants contain relationships between applications and topics. Applications have relationships with other applications via topics. Groups have relationships with other groups through grants.
Add functionality to the DPM to show these relationships in a graphical manner. A relationship can only be included in the graph if 1) the user has access to the link or 2) both ends of the link are marked as public. (Do we need to have public/private for grants?)
The static graphs can be augmented with dynamic data from the RtpsRelay to generate a realtime picture of dataflow.
The "public" page for a group, topic, application, or grant is a prime candidate for showing the dataflow graph for a particular item. Initially, the graph could contain the item and its immediate neighbors. For display purposes, the nodes of the graph are Applications and Topics and the directed edges indicate that an application writes/reads the topic. Applications will have one shape/styling while Topics will have another. All Topics and Applications belonging to a group will have the same color which is determined by hashing the group’s name. Mousing over a node should highlight all nodes belonging to that group. The page will have a button to grow the graph by adding nodes that are one link away from any node on the graph. The page will also have a reset button to reset the graph to its original state. Right-clicking on a node reveals a menu will two options:
- Grow - add nodes that are one link away from the selected node.
- Expand - add all nodes for the group that owns the node.