You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ambari.apache.org by Alexander Denissov <ad...@pivotal.io> on 2015/03/11 00:08:53 UTC
How to propagate property changes ?
I wonder what is the best way to propagate property changes other than to
restart the service ?
Let's say we want to change a few properties in *-site.xml for the service,
and need these properties to be updated in the files on the actual nodes.
Then, we would like to perform some upgrade steps and only then start the
service. Starting the service just to pick up changed properties is not
ideal as the service start will fail as it has not yet been upgraded.
We are using Ambari 1.7.0.
--
Thanks,
Alex.
Re: How to propagate property changes ?
Posted by Alexander Denissov <ad...@pivotal.io>.
Thanks Nate,
This worked for hdfs-site.xml, where the API call pushed changes to the
file, however, hadoop-env.sh was left intact, even though I changed JVM
properties. As expected, hadoop-env.sh got re-written when I restarted the
services. Are there limitations on which kinds of config files can be
configured using this CONFIGURE API ?
Also, it seems that I would need to issue a separate call for each
component of HDFS and provide the list of hosts this component runs on. Is
there a way to call a single API and just give "HDFS" as a service name and
have Ambari back-end figure out what components on what hosts need to be
configured ? Setting level to "CLUSTER" didn't have any effect as
"component_name" and "hosts" seem to be always required.
--
Thanks,
Alex.
On Wed, Mar 18, 2015 at 9:35 AM, Nate Cole <nc...@hortonworks.com> wrote:
> One small clarification, the verb should be POST, not PUT.
>
> -Nate
>
>
> > On Mar 18, 2015, at 8:14 AM, Nate Cole <nc...@hortonworks.com> wrote:
> >
> > Hi Alexander,
> >
> > Apologies for the delayed response on this. The ability to refresh
> configs for any host component doesn’t appear to be exposed in the UI. It
> is possible, however to use the API directly to invoke the configure()
> action like so:
> >
> > PUT /api/v1/clusters/<cluster>/requests
> > {
> > "RequestInfo": {
> > "command":"CONFIGURE",
> > "context":"Reconfigure NameNode",
> > "operation_level": {
> > "level":"HOST",
> > "cluster_name": “<cluster>"
> > }
> > },
> > "Requests/resource_filters": [
> > {
> > "service_name":"HDFS",
> > "component_name":"NAMENODE",
> > "hosts”: “h1"
> > }
> > ]
> > }
> >
> > This is just one example, you can change the resource_filter and/or
> operation_level to meet your needs.
> >
> > Thanks,
> > Nate
> >
> >> On Mar 10, 2015, at 7:08 PM, Alexander Denissov <ad...@pivotal.io>
> wrote:
> >>
> >> I wonder what is the best way to propagate property changes other than
> to restart the service ?
> >>
> >> Let's say we want to change a few properties in *-site.xml for the
> service, and need these properties to be updated in the files on the actual
> nodes. Then, we would like to perform some upgrade steps and only then
> start the service. Starting the service just to pick up changed properties
> is not ideal as the service start will fail as it has not yet been upgraded.
> >>
> >> We are using Ambari 1.7.0.
> >>
> >> --
> >> Thanks,
> >> Alex.
> >
>
>
Re: How to propagate property changes ?
Posted by Nate Cole <nc...@hortonworks.com>.
One small clarification, the verb should be POST, not PUT.
-Nate
> On Mar 18, 2015, at 8:14 AM, Nate Cole <nc...@hortonworks.com> wrote:
>
> Hi Alexander,
>
> Apologies for the delayed response on this. The ability to refresh configs for any host component doesn’t appear to be exposed in the UI. It is possible, however to use the API directly to invoke the configure() action like so:
>
> PUT /api/v1/clusters/<cluster>/requests
> {
> "RequestInfo": {
> "command":"CONFIGURE",
> "context":"Reconfigure NameNode",
> "operation_level": {
> "level":"HOST",
> "cluster_name": “<cluster>"
> }
> },
> "Requests/resource_filters": [
> {
> "service_name":"HDFS",
> "component_name":"NAMENODE",
> "hosts”: “h1"
> }
> ]
> }
>
> This is just one example, you can change the resource_filter and/or operation_level to meet your needs.
>
> Thanks,
> Nate
>
>> On Mar 10, 2015, at 7:08 PM, Alexander Denissov <ad...@pivotal.io> wrote:
>>
>> I wonder what is the best way to propagate property changes other than to restart the service ?
>>
>> Let's say we want to change a few properties in *-site.xml for the service, and need these properties to be updated in the files on the actual nodes. Then, we would like to perform some upgrade steps and only then start the service. Starting the service just to pick up changed properties is not ideal as the service start will fail as it has not yet been upgraded.
>>
>> We are using Ambari 1.7.0.
>>
>> --
>> Thanks,
>> Alex.
>
Re: How to propagate property changes ?
Posted by Nate Cole <nc...@hortonworks.com>.
Hi Alexander,
Apologies for the delayed response on this. The ability to refresh configs for any host component doesn’t appear to be exposed in the UI. It is possible, however to use the API directly to invoke the configure() action like so:
PUT /api/v1/clusters/<cluster>/requests
{
"RequestInfo": {
"command":"CONFIGURE",
"context":"Reconfigure NameNode",
"operation_level": {
"level":"HOST",
"cluster_name": “<cluster>"
}
},
"Requests/resource_filters": [
{
"service_name":"HDFS",
"component_name":"NAMENODE",
"hosts”: “h1"
}
]
}
This is just one example, you can change the resource_filter and/or operation_level to meet your needs.
Thanks,
Nate
> On Mar 10, 2015, at 7:08 PM, Alexander Denissov <ad...@pivotal.io> wrote:
>
> I wonder what is the best way to propagate property changes other than to restart the service ?
>
> Let's say we want to change a few properties in *-site.xml for the service, and need these properties to be updated in the files on the actual nodes. Then, we would like to perform some upgrade steps and only then start the service. Starting the service just to pick up changed properties is not ideal as the service start will fail as it has not yet been upgraded.
>
> We are using Ambari 1.7.0.
>
> --
> Thanks,
> Alex.