> On May 30, 2017, 5:42 p.m., Jonathan Hurley wrote:
> > I think that the overall problem here is how the UI determines that before 
> > you can enable NN HA, you must first add ZK to the cluster. Alejandro's 
> > concern is that the UI shouldn't have this responsibility - it should be 
> > declared somewhere on the stack. This way, the UI can query to determine if 
> > any services are missing.
> > 
> > Is there a way which we can accomplish this? It seems to be a general 
> > workflow issue. 
> > 
> > I saw that NN has a general dependency on ZK if HA is enabled via a 
> > property condition:
> > 
> >             <dependency>
> >               <name>ZOOKEEPER/ZOOKEEPER_SERVER</name>
> >               <scope>cluster</scope>
> >               <auto-deploy>
> >                 <enabled>false</enabled>
> >               </auto-deploy>
> >               <conditions>
> >                 <condition xsi:type="propertyExists">
> >                   <configType>hdfs-site</configType>
> >                   <property>dfs.nameservices</property>
> >                 </condition>
> >               </conditions>
> >             </dependency>
> >             
> >  So this is currently modeled in the metainfo.xml which is good. The 
> > question is what currently uses this information to enforce that ZK is a 
> > part of the cluster _PRIOR_ to enabling NN HA.
> 
> Tim Thorpe wrote:
>     As far as I know those dependencies are only used by the new stack 
> advisor code in AMBARI-19685 (to validate the layout) and will be in 
> AMBARI-20122 (to recommend the layout).  Those conditions should also be 
> honoured by the stack advisor recommendation and validation of the 
> configurations.  They may be used by blueprints but I'm not all that familiar 
> with that code.
>     
>     For special processes like enabling NN HA, the whole process is already 
> hard coded into the UI.  This includes a check on whether there are at least 
> 3 zookeeper nodes.
>     
>     My option 3 (the one Alejandro liked) is actually redundant with what is 
> already there in the conditional dependencies AND it doesn't actually help 
> with the problem in question.  If the UI needs to know what operations it can 
> run then we'd need to do something with the custom commands section.  We 
> could potentially add something like this:
>     
>                 <customCommand>
>                   <name>ENABLE_NAMENODE_HA</name>
>                   <commandScript>
>                     <script>scripts/namenode.py</script>
>                     <scriptType>PYTHON</scriptType>
>                     <timeout>600</timeout>
>                   </commandScript>
>                   <dependency>
>                     <name>ZOOKEEPER/ZOOKEEPER_SERVER</name>
>                     <type>service</type>
>                     <scope>cluster</scope>
>                     <cardinality>3+</cardinality>
>                   </service-dependency>
>                 </customCommand>
>     
>     I'm not sure how many other services would actually be able to make use 
> of something like this.  Currently enabling HA is completely hard coded in 
> the UI and there is nothing about it in the metainfo.xml (this is true for 
> both HDFS and YARN).  I just don't see this extra work as really being of 
> much benefit.  If we can actually find at least one place where this would 
> help with the current services then I'd be fine with adding it.

I also think that there's some parallel work being done now to introduce some 
kind of workflow framework into Ambari which would offload the work from the 
UI. In that case, this would be triple-redundant work. I'm OK with what you 
have now ...


- Jonathan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59095/#review176366
-----------------------------------------------------------


On May 9, 2017, 10:39 a.m., Tim Thorpe wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59095/
> -----------------------------------------------------------
> 
> (Updated May 9, 2017, 10:39 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Di Li, Jonathan Hurley, 
> Jayush Luniya, and Nate Cole.
> 
> 
> Bugs: AMBARI-20967
>     https://issues.apache.org/jira/browse/AMBARI-20967
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> HDFS has a static dependency on Zookeeper even though it is only needed when 
> NameNode HA is enabled. The check for Zookeeper should be done before 
> enabling HA rather than enforcing it at installation time.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/metainfo.xml 
> 3026938 
> 
> 
> Diff: https://reviews.apache.org/r/59095/diff/1/
> 
> 
> Testing
> -------
> 
> mvn clean test
> 
> Manual testing - installed HDFS only cluster and attempted to enable NameNode 
> HA.  This is prevented with the same error you'd see if ZooKeeper was enabled 
> but you had fewer than 3 ZooKeeper servers configured.
> 
> 
> Thanks,
> 
> Tim Thorpe
> 
>

Reply via email to