You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Steve Varnau <st...@esgyn.com> on 2016/11/15 02:29:07 UTC

Advice on Ambari M-Pack

Ambari developers,

I'm working on an Ambari MPack to add a service for Trafodion (Apache incubating).  I've figured out the basics, but I'm not sure of the best technique when my service needs to modify config values for another service. In this case, we install an HBase co-processor, which is done by modifying HBase config parameters (ex: hbase.coprocessor.region.classes).

Should my MPack be trying to modify the HBase defaults, so that they are presented to the user at config time? Or should my install steps be instantiating config values somehow that HBase will pick up?  Or is there some better way?

Thanks for any advice.

--Steve


Re: Advice on Ambari M-Pack

Posted by Steve Varnau <sv...@apache.org>.
That is the pointer I needed! Thanks, Matt.

-Steve

On 2016-11-14 19:53 (-0800), Mithun Mathew <mi...@gmail.com> wrote: 
> Hi Steve
> 
> 
> You should look into recommending configurations during install time of
> your service. This lets the user know what options are being changed as a
> result of installing the service, and gives the user a chance to accept,
> modify or reject your recommendations.
> 
> This can be done by implementing a service advisor (ideally, this should
> work within the m-pack).
> 
> Ambari Wiki:
> https://cwiki.apache.org/confluence/display/AMBARI/Service+Advisor
> 
> Here's an example of a service_advisor recommending configurations for
> HDFS:
> https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/HAWQ/2.0.0/service_advisor.py#L131-L149
> 
> 
> Regards
> Matt
> 
> On Mon, Nov 14, 2016 at 6:29 PM, Steve Varnau <st...@esgyn.com>
> wrote:
> 
> > Ambari developers,
> >
> > I'm working on an Ambari MPack to add a service for Trafodion (Apache
> > incubating).  I've figured out the basics, but I'm not sure of the best
> > technique when my service needs to modify config values for another
> > service. In this case, we install an HBase co-processor, which is done by
> > modifying HBase config parameters (ex: hbase.coprocessor.region.classes).
> >
> > Should my MPack be trying to modify the HBase defaults, so that they are
> > presented to the user at config time? Or should my install steps be
> > instantiating config values somehow that HBase will pick up?  Or is there
> > some better way?
> >
> > Thanks for any advice.
> >
> > --Steve
> >
> >
> 
> 
> -- 
> *Mithun Mathew* (Matt)
> 
>    - www.linkedin.com/in/mithunmatt/
> 


Re: Advice on Ambari M-Pack

Posted by Mithun Mathew <mi...@gmail.com>.
Hi Steve


You should look into recommending configurations during install time of
your service. This lets the user know what options are being changed as a
result of installing the service, and gives the user a chance to accept,
modify or reject your recommendations.

This can be done by implementing a service advisor (ideally, this should
work within the m-pack).

Ambari Wiki:
https://cwiki.apache.org/confluence/display/AMBARI/Service+Advisor

Here's an example of a service_advisor recommending configurations for
HDFS:
https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/HAWQ/2.0.0/service_advisor.py#L131-L149


Regards
Matt

On Mon, Nov 14, 2016 at 6:29 PM, Steve Varnau <st...@esgyn.com>
wrote:

> Ambari developers,
>
> I'm working on an Ambari MPack to add a service for Trafodion (Apache
> incubating).  I've figured out the basics, but I'm not sure of the best
> technique when my service needs to modify config values for another
> service. In this case, we install an HBase co-processor, which is done by
> modifying HBase config parameters (ex: hbase.coprocessor.region.classes).
>
> Should my MPack be trying to modify the HBase defaults, so that they are
> presented to the user at config time? Or should my install steps be
> instantiating config values somehow that HBase will pick up?  Or is there
> some better way?
>
> Thanks for any advice.
>
> --Steve
>
>


-- 
*Mithun Mathew* (Matt)

   - www.linkedin.com/in/mithunmatt/