CNF-14144: Add resource server enhancements doc #262
Conversation
This adds a document describing the proposal to change the resource server architecture to address performance and scalability concerns. Signed-off-by: Allain Legacy <[email protected]>
|
@alegacy: This pull request references CNF-14144 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.18.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
|
/cc @pixelsoccupied |
docs/enhancements/infrastructure-inventory-services-api/resource-server.md
Show resolved
Hide resolved
docs/enhancements/infrastructure-inventory-services-api/resource-server.md
Show resolved
Hide resolved
docs/enhancements/infrastructure-inventory-services-api/resource-server.md
Outdated
Show resolved
Hide resolved
docs/enhancements/infrastructure-inventory-services-api/resource-server.md
Show resolved
Hide resolved
docs/enhancements/infrastructure-inventory-services-api/resource-server.md
Show resolved
Hide resolved
docs/enhancements/infrastructure-inventory-services-api/component-diagram.svg
Outdated
Show resolved
Hide resolved
docs/enhancements/infrastructure-inventory-services-api/resource-server.md
Outdated
Show resolved
Hide resolved
| attributes will be normalized into the formal model definition. The following subsection lists the extensions currently | ||
| stored within the extensions attribute and passed directly onto the public facing API. | ||
|
|
||
| #### Resource Pool |
There was a problem hiding this comment.
We will also need the H/W server resource pools
| For nodes from hardware managers: | ||
|
|
||
| ```json | ||
| { |
There was a problem hiding this comment.
We would also need to look at exposing nics and accelerators ( FEC, GPUS etc)
| "cores": "TBD", | ||
| "bios": "TBD", | ||
| "memory": "TBD" | ||
| } |
There was a problem hiding this comment.
Probably want the server variant here as well
| This feature depends on the Postgres service being deployed, This work is to be completed as part of the alarm server | ||
| feature development {TBD Reference}. | ||
|
|
||
| ## Consolidation of microservices |
Addresses PR comments Signed-off-by: Allain Legacy <[email protected]>
| Ideally, since re-syncing is a resource intensive process, it would be best to not do a periodic sync for any data | ||
| source which supports an asynchronous event notifications mechanism. However, given that these other software |
There was a problem hiding this comment.
Implementation details...but if all these resources are k8s CRs, we can simply setup a watch on them with client-go? We basically setup a listen with SharedInformerFactory and just react on based on events (add/delete/etc). This way we dont really need to keep track of generation IDs and such (k8s will take care of that for us)
There was a problem hiding this comment.
No, they won't be k8s CRs in most cases because we'll be importing data from ACM, and h/w managers... so direct polling will be required.
| - The resource server will push any changes to the resource type table to the alarm server | ||
| - The resource server will pull the latest alarm dictionary data on startup | ||
| - The alarm server will push any changes to the alarm dictionary table to the resource server | ||
| - The alarm server will pull the latest resource type data on startup. |
There was a problem hiding this comment.
Cool basically we will fill in the details for each other. Alarms will ask something like /ResourceType GET...and then we generate the AlarmDictionary rows and respond back with ResourceType and its corresponding AlarmDictionary filled out. We can probably reuse the exact the O-RAN payload for req and response to keep it simple.
There was a problem hiding this comment.
yes, we can probably use the 'standard' API endpoints... maybe.
| ); | ||
|
|
||
| -- Table: resource_type | ||
| CREATE TABLE IF NOT EXISTS resource_type ( |
There was a problem hiding this comment.
will you keep a copy of the AlarmDictionary? But maybe a call to alarm server will do the trick. Basically what happens when client requests to list all the resourceType after the server is ready?
There was a problem hiding this comment.
Yes, as discussed we'll keep a cached copy of the alarm dictionary/definitions and refresh it periodically and based on notifications from the alarm server. See diagram.
|
@alegacy: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This adds a document describing the proposal to change the resource server architecture to address performance and scalability concerns.