-
Notifications
You must be signed in to change notification settings - Fork 7
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
Modify the Node
structure
#401
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #401 +/- ##
==========================================
+ Coverage 68.19% 68.81% +0.61%
==========================================
Files 95 96 +1
Lines 20320 20871 +551
==========================================
+ Hits 13857 14362 +505
- Misses 6463 6509 +46 ☔ View full report in Codecov by Sentry. |
999d9f8
to
829cfa5
Compare
src/tables/node.rs
Outdated
@@ -14,7 +14,7 @@ use crate::{ | |||
}; | |||
|
|||
#[derive(Default, Debug, Clone, Serialize, Deserialize, PartialEq)] | |||
pub struct Giganto { | |||
pub struct ConnectionlessAgent { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While Agent
has a key for each instance, ConnectionlessAgent
does not. Additionally, Agent
s are represented as a Vec<Agent>
, whereas ConnectionlessAgent
s are instantiated individually, like giganto
and ti_container
. Furthermore, ConnectionlessAgent
includes its status through the AgentStatus
field. These differences highlight inconsistencies, and on top of that, the name ConnectionlessAgent
doesn't seem ideal to convey the true meaning. I believe we need a better approach to address these inconsistencies and clarify the concept.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed, it would be nice to introduce the Remote
struct to handle remote servers that do not use QUIC communication. It will be similar to Agent
in many ways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll proceed with the modifications in that direction.
- Modify the `Node` structure to allow you to manage the configuration of all remote servers that communicate with the REview. - Introduces `Remote`, a new structure that stores configuration information for remote servers. The data in `Remote` is stored via `Table<Remote>`. - Add a `remotes` field of type `Vec<Remote>` within the `Node` structure to store the all remote server configuration. - Add a `Datalake`, `TiContainer` field inside `node::kind`. - Modify migration function `migrate_0_29_node`. - Add migration function`migrate_0_35_node`. Close: petabi#399
829cfa5
to
f8fdb79
Compare
@sehkone |
Thank you for what you've done. I will review the code soon. |
Node
structure to allow you to manage the configuration of all remote servers that communicate with the REview.Remote
, a new structure that stores configuration information for remote servers. The data inRemote
is stored viaTable<Remote>
.remotes
field of typeVec<Remote>
within theNode
structure to store the all remote server configuration.Datalake
,TiContainer
field insidenode::kind
.migrate_0_29_node
.migrate_0_35_node
.Close: #399
Migration Test
nodeList
query