Replace the eservice json database with a more functional database that can be used for all service types #447
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
bvavala
approved these changes
Aug 31, 2023
The eservice database was limited by what it could store (just enclave services), how it was stored (full file load/save), and how the information was exported. The old eservice database is replaced by a persistent database (implemented with lmdb) that stores information about all services. The database is loaded on first use (similar to the block store manager) from settings in the configuration file. Signed-off-by: Mic Bowman <[email protected]>
Signed-off-by: Mic Bowman <[email protected]>
…ucturing Signed-off-by: Mic Bowman <[email protected]>
Move file handling for import/export of service group and service data into the shell commands leaving the group and data code independent of the ultimate file format (shell commands use TOML with configuration expansions). Update shell test to include the common "service_host" binding variable that we use throughout other tests. Signed-off-by: Mic Bowman <[email protected]>
Signed-off-by: Mic Bowman <[email protected]>
cmickeyb
force-pushed
the
mic.aug22.service_data
branch
from
de4eb06
to
0d18bd1
Compare
prakashngit
approved these changes
Sep 12, 2023
| return serialized | ||
|
|
||
| def verify(self, ledger_config = None) : | ||
| """ensure that the eservice still exists and hosts the enclave, and |
There was a problem hiding this comment.
i thought in the past, we always verified an entry with ledger before adding to the db ? now it seems that you expect the client to explicitly verify an entry with the ledger after adding to db? (for example, line 523 where you store by url, you are simply calling fetch, but no verify). I am not sure why client would want to add anything to db without verifying.
marcelamelara
approved these changes
Sep 13, 2023
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.
Replace the eservice database with more general service database
The eservice database was limited by what it could store (just enclave services), how it was stored (full file load/save), and how the information was exported.
The old eservice database is replaced by a persistent database (implemented with lmdb) that stores information about all services. The database is loaded on first use (similar to the block store manager) from settings in the configuration file.
The eservice_db pdo-shell command is replaced with one for all service databases (using the new format).