feat: auto resync when session expire or host reboot #36
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
scott-howe-1
force-pushed
the
feature/re-sync-after-endpoint-power-cycle
branch
from
f288c9e
to
b816540
Compare
…-endpoint-power-cycle
Needed to combine new auto-resync with recently added online\offline status functionality. New DeleteBladeByIdBackend() gives service the ability to only delete sessions from the backend. This allows the webui to still see the blade, even if it's powered down. New UpdateBladeById() give service the ability to update (resync) an existing blade that's already visible to the client. Created a new "found" Status state for devices (which represents "powered" but with no valid redfish session id).
Previous commit should have been a feat(service):, not fix:. Needed to combine new auto-resync with recently added online\offline status functionality. New DeleteHostByIdBackend() gives service the ability to only delete sessions from the backend. This allows the webui to still see the host, even if it's powered down. New UpdateHostById() gives service the ability to update (resync) an existing host that's already visible to the client. Created a new "found" Status state for devices (which represents "powered" but with no valid redfish session id).
Two things were added to the frontend code, logging and a client api entry mutex. NO performance issues were seen after adding the mutex. The mutex may get removed later, but it is helping right now. There are 2 reason for adding these items: First, there has historically been no logging in this frontend layer. This has made the service logs hard to read when we're not sure which client api has been requested. Second, the service log output did NOT show sychronous API execution. One or more API's are logging as started BEFORE previous ones were completed. So, the mutex was added to: 1.) improve log readability (no inter-mixed api logging output) 2.) Ensure that the service code is executed in a synchronous manner, as it is not designed to run asychrounously.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.