Summary
As a user, I would like to set config options dynamically.
As many administrative activities are being migrated to the GraphQL layer, it sounds elementary to add other functionalities as well to GraphQL Admin. Making easier the user’s life.
PS. Feels like some of this is already implemented (lruMB?). As it was an old internal request. But I’ll create this RFC anyway. Also, feels like something is missing on it tho.
Please, share your thoughts and vote for it.
Motivation
Facilitate cluster administration without having to restart all Dgraph instances. Only to change non-definitive values and the ones that don’t require restarting the instances. (I mean, non-crucial config options)
Use cases
Sometimes we need to do small operations, but they can be related to the use of some parameters to be defined via config options. For example, we want a remote application to have momentary access to the cluster, however, we need to add some parameters like --whitelist. And this is blocking. Because to do this small task, you need to shutdown the instance and then add the value to the flag and start again.
Sometimes we want to increase the RAM of some instances, and consequently provide Dgraph with more resources. However, config options like LRU need to be manually modified via flag. This requires restarting the instance.
--mutations this is one of the most important parameters. Giving the user flexibility to block and unblock mutations quickly.
--abort_older_than, --export, --graphql_poll_interval, --snapshot_after, --pending_proposals, --query_edge_limit
Above we have all types of parameters that could be modified dynamically. These are important configurations that could be modified while the Cluster is alive.
Some flags obviously require instances to be restarted. Inevitable, but others would make the user’s life much easier. The more parameters we have via GraphQL, the better.
User Impact
Users will be able to modify key configs options on the fly. Facilitating the administration of the Cluster in general.
Users will now have access to the above-mentioned configs options via GraphQL Admin. Through a mutation, they can activate and deactivate functions in the Cluster or in the specific instance.
Proposal examples.
--whitelist
input WhitelistInput {
"""
A comma separated list of IP ranges you wish to whitelist for performing admin actions (i.e., --whitelist 127.0.0.1:127.0.0.3,0.0.0.7:0.0.0.9)
"""
whitelist: String
"""
Choose in which instance to apply the new config value.
"""
instanceId: Int
}
type WhitelistPayload {
response: Response
}
--export
input ExportPathInput {
"""
Destination for the export: e.g. /absolute/path
"""
destination: String
"""
Choose in which instance to apply the new config value.
"""
instanceId: Int
}
type ExportPathPayload {
response: Response
}
--lru_mb
As the lru_mb already exists, I’m only adding the instanceId param.
type LRUPatch {
"""
Estimated memory the LRU cache can take. Actual usage by the process would be
more than specified here. (default -1 means no set limit)
"""
lruMb: Float
"""
Choose in which instance to apply the new config value.
"""
instanceId: Int
}
--mutations
input mutationsInput {
"""
Set mutation mode to allow, disallow, or strict. (default "allow")
"""
mode: String
"""
Choose in which instance to apply the new config value.
"""
instanceId: Int
}
input ConfigInput {
"""
Folder in which to store exports. (default "export")
"""
exportPath(input: ExportPathInput!): ExportPathPayload
mutations(input: mutationsInput!): mutationsPayload!
lruMb: LRUPatch!
"""
True value of logRequest enables logging of all the requests coming to alphas.
False value of logRequest disables above.
"""
logRequest: Boolean
}
FYI: @pawan, @LGalatin - I have created this related to a deleted ticket. I think this makes it more clear.
Update 2020:
We have a new dynamic config
