ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shantanu Mundkur (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMBARI-14123) Inconsistencies in UI handling of component cardinality
Date Tue, 01 Dec 2015 08:55:11 GMT
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)

Mime
View raw message