Shantanu Mundkur created AMBARI-14123:
-----------------------------------------
Summary: Inconsistencies in UI handling of component cardinality
Key: AMBARI-14123
URL: https://issues.apache.org/jira/browse/AMBARI-14123
Project: Ambari
Issue Type: Bug
Components: ambari-web
Affects Versions: 2.1.0, 2.1.1, 2.1.2
Reporter: Shantanu Mundkur
Fix For: 2.2.0
There were several inconsistencies noted in how component cardinality is
presently handled by the Ambari UI. some of these inconsistencies might be
considered a reasonable limitation if a warning is displayed to alert the user
about the inconsistency.
1) A MASTER component is shown on the "Assign Masters" page with a selection
that does not match the minimum cardinality specified in the service
definition. For instance, 2+ will still result in only 1 host being assigned
for the component. The user has to manually click on + and add additional
hosts. There is no warning either that the selection does not match the
requirement (e.g. minimum of 2).
2) There is no option that allows zero MASTER components from the outset of a
new installation (assuming optional MASTER components could be a requirement
for some services). As the behavior is today, the only way to achieve a
cardinality of 0 for MASTER component would be to use a cardinality of 0+ and
then delete the instance of the component post-install.
3) If a MASTER component specifies a cardinality of ALL then this is not
represented correctly as one instance/host for the component is pre-selected.
Instead, maybe there should be an indication that the component will be
installed on every host and the user be disallowed from any selection that is
an obvious inconsistency.
3) Clubbing together of SLAVE and CLIENT via the "Assign Slaves and Clients"
page gives rise to a couple of problems.
i) With a cardinality ALL for SLAVE as well as for CLIENT component, ALL is
enforced by skipping the "Assign Slaves and Clients" Page. This might be fine
though an alternate representation for cardinality ALL might be preferable as
would be apparent from the rest of the details provided here.
If the SLAVE of any selected service has some cardinality other than ALL then
the page is not skipped. This means somebody could try selecting the number of
CLIENTs as well via the checkboxes. If the CLIENT cardinality is ALL then the
checkbox selection is ignored silently and without any warnings.
ii) Combinations of cardinality for components of multiple services when
multiple services are being installed or added, can be hard to respresent via
the UI. For instance, when CLIENT component for these services have conflicting
cardinality, the user would not be able to completely get rid of the warning
message and might see for example:
" Exactly 3 Service1 Client components should be installed in cluster.
Exactly 2 Service2 Client components should be installed in cluster."
Obviously, one or the other could be resolved but not both.
One might just have to proceed ignoring the warning or else choose to install
the services separately, one at a time. Maybe no change is needed here but I am
including this observation for completeness.
4) Validation of MASTER and CLIENT component cardinality via stack advisor
logic might not be working as expected as some warnings are not surfaced out to
the user or for that matter to the log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
