| Summary: | batch not verified for correctness | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Aleksandar Kostadinov <akostadi> |
| Component: | CLI | Assignee: | Alexey Loubyansky <olubyans> |
| Status: | CLOSED EOL | QA Contact: | Petr Kremensky <pkremens> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1.1 | CC: | akostadi, brian.stansberry, myarboro |
| Target Milestone: | --- | ||
| Target Release: | TBD EAP 7 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-19 12:44:31 UTC | Type: | Enhancement |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
True, commands in batches are not validated. There is a reason for that though. Some commands in a batch may depend on the preceding commands in the same batch, i.e. the results of those commands. For example, some addresses may not actually exist when the command is added to the batch but they will during the execution. If we start validating commands then either many of them will fail or we'd have to somehow take into account the effect of the preceding commands on the management model (which, in general, won't be possible on the client side). The batch execution succeeds because the server side doesn't verify arguments. I.e. some argument values are validated when they are recognized. But unrecognized arguments are generally simply ignored. So, it's not an easy one in a sense that general validation rules can't be applied to the commands added to batches. Wouldn't it be good if we have that validation on server side? I think it's better if user gets feedback when there is unknown parameter supplied. A small typo could otherwise have subtle effects because user won't know there was a typo until something breaks. It would. But given that it hasn't been a common practice from the beginning it'd be quite an effort to implement now. The model provides the descriptions of what it supports and delegates the validation to the tools. This is where it fails. I mean, for this specific example reported in the issue, I could get the operation description and check the parameters (because the path exists from the beginning). But if the batch would be something like: /a=b:add(...) /a=b/c=d:add(...) /a=b/c=d:some-op(p1=1,p2=2) I might not be able to get the description of some-op (and, hence, validate its parameters) until the path to d exists. I am changing the type to Enhancement since what is originally described is the expected behavior, although unfortunately. |
> batch > /subsystem=web/connector=https:add(enabled="true", secure="true", enableLookups="false", scheme="https", disableUploadTimeout="true", maxThreads="150", maxHttpHeaderSize="8192", SSLCertificateFile="/tmp/www.example.com.cert", SSLCertificateKeyFile="/tmp/www.example.com.key", socket-binding="https", protocol="HTTP/1.1", SSLEnabled="true") > run-batch This is an incorrect command within the batch but its outcome is success. Unknown parameters are simply ignored. If the same command is executed outside a batch, then it properly fails with an error telling there are unknown parameters.