Deploying cluster using blueprint must respect RCO. Otherwise, traditional configuration manager system like chef and puppet can already do the job of Ambari. The advantage of Ambari over other system is to ensure that cross node service dependencies are generated by dependency description model and allow Ambari server to create orchestrating plan accordingly. If there is feature request about the optimization of installation timing, that request should be handled independently from sacrificing RCO dependencies. This sounds like a critical defect to fix.
On Fri, Mar 11, 2016 at 4:18 PM, Alejandro Fernandez < afernan...@hortonworks.com> wrote: > +others who have more insight into BluePrints > > On 3/11/16, 3:24 PM, "Bhuvnesh Chaudhary" <bchaudh...@pivotal.io> wrote: > > >Hello Sebastian, Alejandro, Andrew, > > > >Referring to the discussion on RB: https://reviews.apache.org/r/43948 > ><https://reviews.apache.org/r/43948/#review120537>, it appears that while > >deploying clusters using Blueprints, RCO is not honored. Please confirm if > >this understanding is correct. > > > >While running internal test suites for HAWQ, we deploy the clusters using > >BP, and we need a specific order in which the HAWQ components must be > >initialized / started. > > > >"HAWQ Standby" component should be initialized after "HAWQ Master" > >component as it has to copy the contents from HAWQ Master. However, since > >RCO is not honored, we often come across issues as HAWQ Standby start / > >initialization before HAWQ Master. > > > >Could you please let us know if there any work already going on for > >bringing in RCO dependency for Blueprints, if not is there any other > >alternative which can be used to enforce the dependency locally, or > >something else which you suggest. > > > >Thanks, > >Bhuvnesh Chaudhary > >Email: bchau <bchaudh...@gopivotal.com>dh...@pivotal.io > >Desk: +1-650-846-1696 | Mobile: +1-973-906-6976 > >
