Return-Path: X-Original-To: apmail-ambari-user-archive@www.apache.org Delivered-To: apmail-ambari-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 19C7111133 for ; Tue, 22 Jul 2014 12:16:31 +0000 (UTC) Received: (qmail 49743 invoked by uid 500); 22 Jul 2014 12:16:30 -0000 Delivered-To: apmail-ambari-user-archive@ambari.apache.org Received: (qmail 49714 invoked by uid 500); 22 Jul 2014 12:16:30 -0000 Mailing-List: contact user-help@ambari.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ambari.apache.org Delivered-To: mailing list user@ambari.apache.org Received: (qmail 49704 invoked by uid 99); 22 Jul 2014 12:16:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jul 2014 12:16:30 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of greg.hill@rackspace.com designates 173.203.4.135 as permitted sender) Received: from [173.203.4.135] (HELO mx1.ord1.rackspace.com) (173.203.4.135) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jul 2014 12:16:28 +0000 X-SBRS: None X-SenderGroup: RELAYLIST-US X-MailFlowPolicy: $RELAYED-US X-IronPort-AV: E=McAfee;i="5600,1067,7471"; a="347782590" X-IronPort-AV: E=Sophos;i="5.01,489,1400043600"; d="scan'208,217";a="347782590" Received: from ord1exh01.rackspace.corp ([10.12.120.25]) by mx1.ord1.rackspace.com with ESMTP/TLS/AES128-SHA; 22 Jul 2014 07:16:01 -0500 Received: from ORD1EXD01.RACKSPACE.CORP ([fe80::6062:da14:84f2:f8b5]) by ORD1EXH01.RACKSPACE.CORP ([::1]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 07:16:01 -0500 From: Greg Hill To: "user@ambari.apache.org" Subject: Re: stopping host components via API Thread-Topic: stopping host components via API Thread-Index: AQHPos0nfE1I4+VCL0if8HDLb8una5um21+AgAOnEYCAAFGDgIAAd/aAgAC74YA= Date: Tue, 22 Jul 2014 12:16:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.195.201.66] Content-Type: multipart/alternative; boundary="_000_CFF3BF4D5DBBgreghillrackspacecom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_CFF3BF4D5DBBgreghillrackspacecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure. It's possible I'm doing something wrong. Setting maintenance mode: PUT /clusters/testcluster/hosts/c6401.ambari.apache.org/host_components?fie= lds=3DHostRoles/state { "RequestInfo": { "context" :"Start Maintanence Mode", }, "Body": { "HostRoles": {"maintenance_state": "ON"}, }, } Stopping all components: PUT /clusters/testcluster/hosts/c6401.ambari.apache.org/host_components?fie= lds=3DHostRoles/state { "RequestInfo": { "context" :"Stop All Components", }, "Body": { "HostRoles": {"state": "INSTALLED"}, }, } From: Srimanth Gunturi > Reply-To: "user@ambari.apache.org" > Date: Monday, July 21, 2014 3:03 PM To: "user@ambari.apache.org" > Subject: Re: stopping host components via API Hi Greg, Was wondering which version of Ambari you were using? When maintenance mode is enabled on service, bulk host operations are ignor= ed. When maintenance mode is enabled on hosts, service level operations are ign= ored on host. So was wondering if you enabled maintenance mode in one level, and performe= d operations on another? I tried the following on trunk, and it stopped all host-components in maint= enance mode. =3D=3D=3D=3D=3D=3D=3D=3D=3D PUT http://c6401:8080/api/v1/clusters/c1/hosts { "RequestInfo": { "context": "Turn On Maintenance Mode for host", "query": "Hosts/host_name.in(c6401.ambari.apache.o= rg)" }, "Body": { "Hosts": { "maintenance_state": "ON" } } } =3D=3D=3D=3D=3D=3D=3D=3D=3D PUT http://c6401:8080/api/v1/clusters/c1/hosts/c6401.ambari.apache.org/host= _components? { "RequestInfo": { "context": "Stop All Host Components", "operation_level": { "level": "HOST", "cluster_name": "c1", "host_names": "c6401.ambari.apache.org" }, "query": "HostRoles/component_name.in(APP_TIM= ELINE_SERVER,DATANODE,HISTORYSERVER,NAMENODE,NODEMANAGER,RESOURCEMANAGER,SE= CONDARY_NAMENODE,ZOOKEEPER_SERVER)" }, "Body": { "HostRoles": { "state": "INSTALLED" } } } =3D=3D=3D=3D=3D=3D=3D=3D=3D Maybe listing the API calls you make might help. Regards, Srimanth On Mon, Jul 21, 2014 at 10:54 AM, Greg Hill > wrote: Anyone know if this is intentional or not? It seems to ignore setting the HostRole/state if the host_component is in maintenance mode. I was able to work around it by immediately setting maintenance mode after changing the state. But that leads to a race condition as to whether nagios notices the downed services before maintenance mode kicks in. IMO, it shouldn't behave this way. There's no safe way to stop services as it is right now. It should let you stop them during maintenance, as that's really the primary reason you'd want to set maintenance. Should I just open a bug? Greg On 7/21/14 8:02 AM, "Greg Hill" > wrote: >I did some debugging and it turns out that the problem is that I set >maintenance mode prior to stopping the components. Unfortunately, this >makes it so nagios starts alerting me. My script is attempting to remove >a slave node from a cluster by doing the following: > >1. Set maintenance mode on all host_components. >2. Stop all host_components. >3. Remove all host_components. >4. Remove host from cluster. > >This was what I had worked out to be the proper procedure a few weeks >back. Am I doing something wrong or did I discover a bug? > >Greg > > >On 7/18/14 7:15 PM, "Yusaku Sako" > wrote: > >>Greg, >> >>That should not be broken. >>What is the exact call you are trying to make (can you post the >>equivalent curl call)? >> >>Yusaku >> >>On Fri, Jul 18, 2014 at 2:13 PM, Greg Hill > >>wrote: >>> This used to be accomplished by doing a PUT with this message to the >>>host >>> resource: >>> >>> {"RequestInfo": {"context" :"Stop All Components"}, "Body": >>>{"HostRoles": >>> {"state": "INSTALLED"}}} >>> >>> But that doesn't appear to work any more. It worked a few weeks ago. >>>Is >>> there somewhere where changes like this are being documented? >>> >>> Greg >> >>-- >>CONFIDENTIALITY NOTICE >>NOTICE: This message is intended for the use of the individual or entity >>to >>which it is addressed and may contain information that is confidential, >>privileged and exempt from disclosure under applicable law. If the reader >>of this message is not the intended recipient, you are hereby notified >>that >>any printing, copying, dissemination, distribution, disclosure or >>forwarding of this communication is strictly prohibited. If you have >>received this communication in error, please contact the sender >>immediately >>and delete it from your system. Thank You. > CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to= which it is addressed and may contain information that is confidential, pr= ivileged and exempt from disclosure under applicable law. If the reader of = this message is not the intended recipient, you are hereby notified that an= y printing, copying, dissemination, distribution, disclosure or forwarding = of this communication is strictly prohibited. If you have received this com= munication in error, please contact the sender immediately and delete it fr= om your system. Thank You. --_000_CFF3BF4D5DBBgreghillrackspacecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5C92F935FFDC6748AE7971FF221ED181@RACKSPACE.CORP> Content-Transfer-Encoding: quoted-printable
Sure.  It's possible I'm doing something wrong.

Setting maintenance mode:

PUT /clusters/testcluster/hosts/c6401.ambari.apache.org/host_comp= onents?fields=3DHostRoles/state
       {
            "RequestInfo": {
                "context&= quot; :"Start Maintanence Mode",
            }, 
            "Body": {
                "HostRole= s": {"maintenance_state": "ON"},
            },
        }

Stopping all components:

PUT /clusters/testcluster/hosts/c6401.ambari.apache.org/host_comp= onents?fields=3DHostRoles/state
       {
            "RequestInfo": {
                "context&= quot; :"Stop All Components",
            }, 
            "Body": {
                "HostRole= s": {"state": "INSTALLED"},
            },
        }

From: Srimanth Gunturi <srimanth@hortonworks.com>
Reply-To: "user@ambari.apache.org" <user@ambari.apache.org>
Date: Monday, July 21, 2014 3:03 PM=
To: "user@ambari.apache.org" <user@ambari.apache.org>
Subject: Re: stopping host componen= ts via API

Hi Greg,
Was wondering which version of Ambari you were using?

When maintenance mode is enabled on service, bulk host operations are = ignored.
When maintenance mode is enabled on hosts, service level operations ar= e ignored on host.
So was wondering if you enabled maintenance mode in one level, and per= formed operations on another?

I tried the following on trunk, and it stopped all host-components in = maintenance mode.
=3D=3D=3D=3D=3D=3D=3D=3D=3D
PUT http://c6401:808= 0/api/v1/clusters/c1/hosts
{
  "RequestInfo": {
    "context": "Turn On Maintenance Mode for host&= quot;,
    "query": "Hosts/host_name.in(c6401.ambari.= apache.org)"
  },
  "Body": {
    "Hosts": {
      "maintenance_state": "ON"
    }
  }
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D
PUT http://c6401:8080/api/v1/clusters/c1/hosts/c6401.ambari.apache.org/host_com= ponents?
{
  "RequestInfo": {
    "context": "Stop All Host Components",     "operation_level": {
      "level": "HOST",
      "cluster_name": "c1",
      "host_names": "c6401.ambari.apache.org"
    },
    "query": "HostRoles/component_name.in(APP_TIMELINE_SERVER,DATANODE,HISTORYSERVER= ,NAMENODE,NODEMANAGER,RESOURCEMANAGER,SECONDARY_NAMENODE,ZOOKEEPER_SERVER)&= quot;
  },
  "Body": {
    "HostRoles": {
      "state": "INSTALLED"
    }
  }
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Maybe listing the API calls you make might help.
Regards,
Srimanth




On Mon, Jul 21, 2014 at 10:54 AM, Greg Hill <greg.hill@= rackspace.com> wrote:
Anyone know if this is intentional or not?  It seems to ignore setting= the
HostRole/state if the host_component is in maintenance mode.  I was ab= le
to work around it by immediately setting maintenance mode after changing the state. But that leads to a race condition as to whether nagios notices<= br> the downed services before maintenance mode kicks in.

IMO, it shouldn't behave this way.  There's no safe way to stop servic= es
as it is right now.  It should let you stop them during maintenance, a= s
that's really the primary reason you'd want to set maintenance.

Should I just open a bug?

Greg

On 7/21/14 8:02 AM, "Greg Hill" <greg.hill@RACKSPACE.COM> wrote:

>I did some debugging and it turns out that the problem is that I set >maintenance mode prior to stopping the components.  Unfortunately,= this
>makes it so nagios starts alerting me.  My script is attempting to= remove
>a slave node from a cluster by doing the following:
>
>1. Set maintenance mode on all host_components.
>2. Stop all host_components.
>3. Remove all host_components.
>4. Remove host from cluster.
>
>This was what I had worked out to be the proper procedure a few weeks >back.  Am I doing something wrong or did I discover a bug?
>
>Greg
>
>
>On 7/18/14 7:15 PM, "Yusaku Sako" <yusaku@hortonworks.com> wrote:
>
>>Greg,
>>
>>That should not be broken.
>>What is the exact call you are trying to make (can you post the
>>equivalent curl call)?
>>
>>Yusaku
>>
>>On Fri, Jul 18, 2014 at 2:13 PM, Greg Hill <greg.hill@rackspace.com>
>>wrote:
>>> This used to be accomplished by doing a PUT with this message = to the
>>>host
>>> resource:
>>>
>>> {"RequestInfo": {"context" :"Stop All= Components"}, "Body":
>>>{"HostRoles":
>>> {"state": "INSTALLED"}}}
>>>
>>> But that doesn't appear to work any more.  It worked a fe= w weeks ago.
>>>Is
>>> there somewhere where changes like this are being documented?<= br> >>>
>>> Greg
>>
>>--
>>CONFIDENTIALITY NOTICE
>>NOTICE: This message is intended for the use of the individual or e= ntity
>>to
>>which it is addressed and may contain information that is confident= ial,
>>privileged and exempt from disclosure under applicable law. If the = reader
>>of this message is not the intended recipient, you are hereby notif= ied
>>that
>>any printing, copying, dissemination, distribution, disclosure or >>forwarding of this communication is strictly prohibited. If you hav= e
>>received this communication in error, please contact the sender
>>immediately
>>and delete it from your system. Thank You.
>



CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the indiv= idual or entity to which it is addressed and may contain information that i= s confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not= the intended recipient, you are hereby notified that any printing, copying= , dissemination, distribution, disclosure or forwarding of this communicati= on is strictly prohibited. If you have received this communication in error, please contact the sender immed= iately and delete it from your system. Thank You.
 --_000_CFF3BF4D5DBBgreghillrackspacecom_--