Bypass empty string check for username and password#5337
Conversation
|
I think we had fixed the issue in Trillian to work-around that @Pearl1594 cc @nvazquez |
harikrishna-patnala
left a comment
There was a problem hiding this comment.
LGTM. the old UI behaves the same as this PR.
|
@blueorangutan package |
|
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔️ el7 ✔️ el8 ✔️ debian. SL-JID 930 |
|
@blueorangutan test |
|
@Pearl1594 a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
| private static final Logger s_logger = Logger.getLogger(ParamProcessWorker.class.getName()); | ||
| public final DateFormat inputFormat = new SimpleDateFormat("yyyy-MM-dd"); | ||
| public final DateFormat newInputFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); | ||
| public static final List<String> avoidList = new ArrayList<>(Arrays.asList("username", "password")); |
There was a problem hiding this comment.
How about using ApiConstants.USERNAME and PASSWORD ?
|
Trillian test result (tid-1718)
|
|
@Pearl1594 |
|
We could do that @weizhouapache - However, my understanding is, if a null / empty uname / password is provided as part of any API args - the corresponding APIs logic would ideally validate the correctness of the input or the authorization would fails if it's empty - which is the assumption that we had even before this check was added by - #5136. |
@Pearl1594 Otherwise, I suggest you change the fields from required to optional in the specific API (add host ?) and check if they are null in codes. |
#5136 is good I think, it fixes some potential missing validations, and causes few regressions (for example the issue you mentioned in PR description). in my opinion, it's better to fix the regression (eg, optional username/password in specific api), instead of rolling back to old behavior (skip validation on username/password in all apis). |
Will do @weizhouapache - Thanks. |
|
@Pearl1594 |
weizhouapache
left a comment
There was a problem hiding this comment.
code lgtm
thanks for fixing @Pearl1594
|
@blueorangutan package |
|
@weizhouapache a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
@weizhouapache I believe this issue is only seen on main branch |
Co-authored-by: dahn <daan.hoogland@gmail.com>
|
@blueorangutan package |
|
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
@Pearl1594 ok, got it. thanks for confirm |
|
Packaging result: ✔️ el7 ✔️ debian. SL-JID 955 |
|
Packaging result: ✔️ el7 ✔️ el8 ✔️ debian ✔️ suse15. SL-JID 958 |
|
@blueorangutan test |
|
@Pearl1594 a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
Trillian test result (tid-1737)
|
|
must be unlucky on that snapshot test |
|
@DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
shwstppr
left a comment
There was a problem hiding this comment.
@Pearl1594 sorry but I don't understand point of this change. We are removing required tag for API params but making them required again in API handling.
Maybe the intention is to check username, password is not empty when they are passed but I don't think the check correspond to that. Sorry if I'm missing something.
username and password can be empty when add a vmware host. |
|
@Pearl1594 is it possible that username and password are empty in cluster details ? |
|
Trillian test result (tid-1741)
|
@weizhouapache even if that's the case - there's a check in place to handle it |
@Pearl1594 ok, that's good. |
| throw new InvalidParameterValueException("Can't specify cluster without specifying the pod"); | ||
| } | ||
| if (!HypervisorType.VMware.toString().equalsIgnoreCase(hypervisorType) && | ||
| (Strings.isNullOrEmpty(username) || Strings.isNullOrEmpty(password))) { |
There was a problem hiding this comment.
We could import org.apache.commons.lang3.StringUtils here and use StringUtils.isAnyEmpty(username, password).
There was a problem hiding this comment.
I agree with @GutoVeronezi.
Nowadays we already have some discussions about adopting org.apache.commons.lang3.StringUtils vs com.cloud.utils.StringUtils "facade" (@DaanHoogland 🙂); with the google.common.base.Strings adds a third variable to this "equation".
Description
Fixes: #5332
This PR attempts to bypass the empty string check added in ParamProcessorValidator - for username and password, so that in case of vmware, it doesn't fail during addition of hosts (where username and password is obtained from cluster details)
Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Added a host to a VMware cluster via UI without any issues.