-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
server: create new memdb table for storing system metadata #8703
Conversation
agent/structs/system_metadata.go
Outdated
Op SystemMetadataOp | ||
|
||
// Entries is the set of keys to modify. | ||
Entries []*SystemMetadataEntry |
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.
How come this accepts a slice rather than a single entry?
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 did not have a use case for multiple atomic updates at this time. It seemed somewhat cheap to make it possible to do multiple atomic updates in the future without having to resort to introducing either another raft operation integer code or to shim this into Txn
.
Alternatively I could do it this way now:
type SystemMetadataRequest struct {
Datacenter String
Op SystemMetadataOp
Entry *SystemMetadataEntry
WriteRequest
}
And then should we need multi-write, we could just do it union style:
type SystemMetadataRequest struct {
Datacenter String
Op SystemMetadataOp
// Only one of Entry or Entries may be specified.
Entry *SystemMetadataEntry
Entries []*SystemMetadataEntry
WriteRequest
}
Thoughts?
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.
Yeah that is a possibility. I lean toward having a single entry per request and revisiting the txn path later.
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.
Left one last comment but will leave it up to you
This adds a new very tiny memdb table and corresponding raft operation for updating a very small effective map[string]string collection of "system metadata". This can persistently record a fact about the Consul state machine itself. The first use of this feature will come in a later PR.
Co-authored-by: Freddy <freddygv@users.noreply.github.com>
62ac140
to
dfd75d2
Compare
This adds a new very tiny memdb table and corresponding raft operation for updating a very small effective map[string]string collection of "system metadata". This can persistently record a fact about the Consul state machine itself. The first use of this feature will come in a later PR.
This adds a new very tiny memdb table and corresponding raft operation
for updating a very small effective map[string]string collection of
"system metadata". This can persistently record a fact about the Consul
state machine itself.
The first use of this feature will come in a later PR.