-
Notifications
You must be signed in to change notification settings - Fork 82
Validation for cluster.brick-multiplex cluster option. #1373
base: master
Are you sure you want to change the base?
Validation for cluster.brick-multiplex cluster option. #1373
Conversation
Can one of the admins verify this patch? |
add to whitelist |
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.
please add e2e for this fix.
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.
We already have the validator function in ClusterOptMap which defines the respective validation function per cluster option. We need to check why the validation isn't being happening through that infra. I don't think we should add validation like this for individual options instead of a generic framework.
@atinmu The validations are happening through that infra. Only thing is that we call RegisterClusterOpValidationFunc() to register these validation functions. |
@atinmu As per our discussion in the morning, I tried using ValidateBool () but its not possible as the validation function for cluster options expects a function with string arguments and the ValidateBool() function has different types of arguments to what is expected for cluster option validation function. |
79c0ecd
to
fca2699
Compare
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.
Also CI seems to have failed from a shd test, please have a look.
optReq := api.ClusterOptionReq{ | ||
Options: map[string]string{"cluster.brick-multiplex": "on"}, | ||
Options: map[string]string{"cluster.brick-multiplex": "invalidValue"}, |
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.
so we don't have a test where we set brick multiplexing to off now?
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.
No, we don't have a test for this as of now but I will add it.
@vpandey-RH Can you please address the comment? |
@atinmu The shd test is failing because max-bricks-per-process is still not merged and in all shd tests I am killing one of the bricks from volume, so if brick-multiplexing is on, killing one brick will result in all bricks going in offline state and that's why the CI fails, saying transport endpoint is not connected. |
@vpandey-RH you should be testing shd on a multi node cluster like environment, running a replica config on the same node isn’t ideal where such behavior can’t be tested. Agree? |
@vpandey-RH CI still fails. |
retest this please |
@vpandey-RH CI failure PTAL |
Discard all garbage strings and allow only "on", "yes", "true", "enable", "1" OR "off", "no", "false", "disable", "0" Signed-off-by: Vishal Pandey <[email protected]>
60e5aa2
to
ebb281e
Compare
@vpandey-RH any update on this PR? |
@atinmu Still working on this. Stuck in an issue regarding local mount by glfsheal binary because of which the self heal tests are failing. |
@vpandey-RH Did we manage to figure out the root cause? |
@atinmu No. I have asked @aravindavk for some help. |
Updates #1367
Add validation to setting cluster.brick-multiplex cluster option.
Discard all garbage strings and allow only "on", "yes", "true", "enable", "1" OR
"off", "no", "false", "disable", "0"
Signed-off-by: Vishal Pandey [email protected]