You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Greg Hill <gr...@RACKSPACE.COM> on 2014/08/21 19:17:27 UTC
setting maintenance mode doesn't return a request id
I have two ways that I know of to enable maintenance mode on a host, but it seems like neither one returns a request id, where pretty much every other API call that generates a request does return an id. Is this a bug?
I'm testing against ambari 1.6.1
PUT http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
{"RequestInfo": {"query": "Hosts/host_name.in(c6404.ambari.apache.org)", "context": "Start Maintenance Mode"}, "Body": {"Hosts": {"maintenance_state": "ON"}}}
Response is a 200 with an empty response body.
Alternatively:
PUT http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c6404.ambari.apache.org/host_components?fields=HostRoles/state
{"RequestInfo": {"context": "Start Maintenance Mode"}, "Body": {"HostRoles": {"maintenance_state": "ON"}}}
Same response. 200 OK, no body.
Thanks in advance for any help.
Greg
Re: setting maintenance mode doesn't return a request id
Posted by Greg Hill <gr...@RACKSPACE.COM>.
Thanks Sid. I've submitted a JIRA -
https://issues.apache.org/jira/browse/AMBARI-6991
Greg
On 8/21/14 5:08 PM, "Siddharth Wagle" <sw...@hortonworks.com> wrote:
>Hi Greg,
>
>The "non-detrministic" time window between issuing the MM request and
>silencing alerts for Host Components is a valid concern.
>
>We should definitely open a Jira for this MM request to be treated as any
>other asycn op.
>
>Regards,
>Sid
>
>
>On Thu, Aug 21, 2014 at 12:39 PM, Dmitry Lysnichenko <
>dlysnichenko@hortonworks.com> wrote:
>
>> Also, how about polling
>>
>> http://vm-0.vm:8080/api/v1/requests?Requests/request_status=IN_PROGRESS
>>
>> to make sure no request is running before deleting hosts?
>>
>>
>> On Thu, Aug 21, 2014 at 10:25 PM, Dmitry Lysnichenko <
>> dlysnichenko@hortonworks.com> wrote:
>>
>> > I mean that Nagios update request is triggered as a side effect for a
>> > request to enable MM (so they are two different requests, one
>> > externally-generated and executed immediately, and one
>> internally-generated
>> > and executed asynchronously)
>> >
>> > Thank you for clarification. The use case you described definitely
>>makes
>> > sense, I'll talk to other devs regarding that.
>> >
>> >
>> > On Thu, Aug 21, 2014 at 10:14 PM, Greg Hill <gr...@rackspace.com>
>> > wrote:
>> >
>> >> Perhaps I should clarify. This is what I'm trying to do:
>> >>
>> >> 1. Set host in maintenance mode
>> >> 2. Stop all host components on that host
>> >> 3. Remove all host components
>> >> 4. Remove host from cluster
>> >>
>> >> If I start #2 before #1 has updated nagios, there is potential for
>> nagios
>> >> to send out down alerts for the components that I'm stopping on
>>purpose.
>> >> It's probably unlikely, but it is nondeterministic. I'd rather know
>> that
>> >> the components are no longer being monitored before I start turning
>>them
>> >> off.
>> >>
>> >> I guess I don't see the philosophical difference between this
>>background
>> >> operation and other background operations. They both show up in the
>> >> Ambari UI in the same place, so I must not be the only one who
>>doesn't
>> see
>> >> the distinction. I'm passing in a Request that spawns a background
>> >> process, so I should get back the Request ID, shouldn't I? What
>> >> understanding am I missing?
>> >>
>> >> Greg
>> >>
>> >> On 8/21/14 1:24 PM, "Dmitry Lysnichenko"
>><dl...@hortonworks.com>
>> >> wrote:
>> >>
>> >> >In this particular case (with a current implementation), you are
>> unlikely
>> >> >to introduce a race condition since the background operation only
>>sends
>> >> to
>> >> >Nagios a list of MM components. So even if you delete some component
>> >> >(except Nagios) while the request is running, nothing bad is going
>>to
>> >> >happen.
>> >> >
>> >> >If we add a response body for this request, the behavior is going to
>> >> >become
>> >> >inconsistent: we will either have or have not a request body
>>depending
>> on
>> >> >Nagios presence in the cluster. Maybe Siddharth Wagle may comment on
>> >> this.
>> >> >
>> >> >
>> >> >On Thu, Aug 21, 2014 at 8:53 PM, Greg Hill <gr...@rackspace.com>
>> >> >wrote:
>> >> >
>> >> >> Right, but I need to wait for that nagios update to finish before
>>I
>> >> >>start
>> >> >> deleting things or I've introduced a race condition with nagios
>> alerts.
>> >> >> How do I poll the status on it if I don't get a request id back?
>> >> >>
>> >> >> Greg
>> >> >>
>> >> >> On 8/21/14 12:47 PM, "Dmitry Lysnichenko" <
>> >> dlysnichenko@hortonworks.com>
>> >> >> wrote:
>> >> >>
>> >> >> >Hi Greg,
>> >> >> >
>> >> >> >Targets are put to MM immediately (during request). The
>>background
>> >> task
>> >> >> >only updates Nagios configuration to ignore alerts for MM
>> components.
>> >> >> >
>> >> >> >
>> >> >> >On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill
>><greg.hill@rackspace.com
>> >
>> >> >> >wrote:
>> >> >> >
>> >> >> >> I guess I'm confused then. It triggers a background task that
>> takes
>> >> >>17s
>> >> >> >> to complete according to the UI, but returns immediately. Is
>>the
>> UI
>> >> >> >> wrong? It definitely isn't immediate; it has to wait for it to
>> >> >>update
>> >> >> >> nagios before it's safe to proceed doing destructive things.
>> >> >> >>
>> >> >> >> Greg
>> >> >> >>
>> >> >> >> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com>
>> >> >>wrote:
>> >> >> >>
>> >> >> >> >Hi Greg,
>> >> >> >> >
>> >> >> >> >A response to a POST request will have a body with the
>>(request
>> id)
>> >> >> >>only
>> >> >> >> >if
>> >> >> >> >the POST request triggers a asynchronous operation and the
>> request
>> >> >>id
>> >> >> >>is a
>> >> >> >> >way of tracking the operation.
>> >> >> >> >
>> >> >> >> >Putting a host in Maintenance mode is not an async op, so
>>this is
>> >> >> >>working
>> >> >> >> >as expected.
>> >> >> >> >
>> >> >> >> >Regards,
>> >> >> >> >Sid
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill
>> >> >><gr...@rackspace.com>
>> >> >> >> >wrote:
>> >> >> >> >
>> >> >> >> >> I have two ways that I know of to enable maintenance mode
>>on a
>> >> >>host,
>> >> >> >>but
>> >> >> >> >> it seems like neither one returns a request id, where pretty
>> much
>> >> >> >>every
>> >> >> >> >> other API call that generates a request does return an id.
>>Is
>> >> >>this a
>> >> >> >> >>bug?
>> >> >> >> >>
>> >> >> >> >> I'm testing against ambari 1.6.1
>> >> >> >> >>
>> >> >> >> >> PUT
>> >> >> >>
>> >> >>>>
>> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
>> >> >> >> >> {"RequestInfo": {"query": "Hosts/host_name.in(
>> >> >> c6404.ambari.apache.org
>> >> >> >> )",
>> >> >> >> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
>> >> >> >> >> {"maintenance_state": "ON"}}}
>> >> >> >> >>
>> >> >> >> >> Response is a 200 with an empty response body.
>> >> >> >> >>
>> >> >> >> >> Alternatively:
>> >> >> >> >>
>> >> >> >> >> PUT
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>>
>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
>> >> >> >> >>04.ambari.apache.org/host_components?fields=HostRoles/state
>> >> >> >> >> {"RequestInfo": {"context": "Start Maintenance Mode"},
>>"Body":
>> >> >> >> >> {"HostRoles": {"maintenance_state": "ON"}}}
>> >> >> >> >>
>> >> >> >> >> Same response. 200 OK, no body.
>> >> >> >> >>
>> >> >> >> >> Thanks in advance for any help.
>> >> >> >> >>
>> >> >> >> >> 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.
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >--
>> >> >> >Thanks,
>> >> >> >Dmitry
>> >> >> >
>> >> >> >--
>> >> >> >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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >Thanks,
>> >> >Dmitry
>> >> >
>> >> >--
>> >> >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.
>> >>
>> >>
>> >
>> >
>> > --
>> > Thanks,
>> > Dmitry
>> >
>>
>>
>>
>> --
>> Thanks,
>> Dmitry
>>
>> --
>> 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,
>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.
Re: setting maintenance mode doesn't return a request id
Posted by Siddharth Wagle <sw...@hortonworks.com>.
Hi Greg,
The "non-detrministic" time window between issuing the MM request and
silencing alerts for Host Components is a valid concern.
We should definitely open a Jira for this MM request to be treated as any
other asycn op.
Regards,
Sid
On Thu, Aug 21, 2014 at 12:39 PM, Dmitry Lysnichenko <
dlysnichenko@hortonworks.com> wrote:
> Also, how about polling
>
> http://vm-0.vm:8080/api/v1/requests?Requests/request_status=IN_PROGRESS
>
> to make sure no request is running before deleting hosts?
>
>
> On Thu, Aug 21, 2014 at 10:25 PM, Dmitry Lysnichenko <
> dlysnichenko@hortonworks.com> wrote:
>
> > I mean that Nagios update request is triggered as a side effect for a
> > request to enable MM (so they are two different requests, one
> > externally-generated and executed immediately, and one
> internally-generated
> > and executed asynchronously)
> >
> > Thank you for clarification. The use case you described definitely makes
> > sense, I'll talk to other devs regarding that.
> >
> >
> > On Thu, Aug 21, 2014 at 10:14 PM, Greg Hill <gr...@rackspace.com>
> > wrote:
> >
> >> Perhaps I should clarify. This is what I'm trying to do:
> >>
> >> 1. Set host in maintenance mode
> >> 2. Stop all host components on that host
> >> 3. Remove all host components
> >> 4. Remove host from cluster
> >>
> >> If I start #2 before #1 has updated nagios, there is potential for
> nagios
> >> to send out down alerts for the components that I'm stopping on purpose.
> >> It's probably unlikely, but it is nondeterministic. I'd rather know
> that
> >> the components are no longer being monitored before I start turning them
> >> off.
> >>
> >> I guess I don't see the philosophical difference between this background
> >> operation and other background operations. They both show up in the
> >> Ambari UI in the same place, so I must not be the only one who doesn't
> see
> >> the distinction. I'm passing in a Request that spawns a background
> >> process, so I should get back the Request ID, shouldn't I? What
> >> understanding am I missing?
> >>
> >> Greg
> >>
> >> On 8/21/14 1:24 PM, "Dmitry Lysnichenko" <dl...@hortonworks.com>
> >> wrote:
> >>
> >> >In this particular case (with a current implementation), you are
> unlikely
> >> >to introduce a race condition since the background operation only sends
> >> to
> >> >Nagios a list of MM components. So even if you delete some component
> >> >(except Nagios) while the request is running, nothing bad is going to
> >> >happen.
> >> >
> >> >If we add a response body for this request, the behavior is going to
> >> >become
> >> >inconsistent: we will either have or have not a request body depending
> on
> >> >Nagios presence in the cluster. Maybe Siddharth Wagle may comment on
> >> this.
> >> >
> >> >
> >> >On Thu, Aug 21, 2014 at 8:53 PM, Greg Hill <gr...@rackspace.com>
> >> >wrote:
> >> >
> >> >> Right, but I need to wait for that nagios update to finish before I
> >> >>start
> >> >> deleting things or I've introduced a race condition with nagios
> alerts.
> >> >> How do I poll the status on it if I don't get a request id back?
> >> >>
> >> >> Greg
> >> >>
> >> >> On 8/21/14 12:47 PM, "Dmitry Lysnichenko" <
> >> dlysnichenko@hortonworks.com>
> >> >> wrote:
> >> >>
> >> >> >Hi Greg,
> >> >> >
> >> >> >Targets are put to MM immediately (during request). The background
> >> task
> >> >> >only updates Nagios configuration to ignore alerts for MM
> components.
> >> >> >
> >> >> >
> >> >> >On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill <greg.hill@rackspace.com
> >
> >> >> >wrote:
> >> >> >
> >> >> >> I guess I'm confused then. It triggers a background task that
> takes
> >> >>17s
> >> >> >> to complete according to the UI, but returns immediately. Is the
> UI
> >> >> >> wrong? It definitely isn't immediate; it has to wait for it to
> >> >>update
> >> >> >> nagios before it's safe to proceed doing destructive things.
> >> >> >>
> >> >> >> Greg
> >> >> >>
> >> >> >> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com>
> >> >>wrote:
> >> >> >>
> >> >> >> >Hi Greg,
> >> >> >> >
> >> >> >> >A response to a POST request will have a body with the (request
> id)
> >> >> >>only
> >> >> >> >if
> >> >> >> >the POST request triggers a asynchronous operation and the
> request
> >> >>id
> >> >> >>is a
> >> >> >> >way of tracking the operation.
> >> >> >> >
> >> >> >> >Putting a host in Maintenance mode is not an async op, so this is
> >> >> >>working
> >> >> >> >as expected.
> >> >> >> >
> >> >> >> >Regards,
> >> >> >> >Sid
> >> >> >> >
> >> >> >> >
> >> >> >> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill
> >> >><gr...@rackspace.com>
> >> >> >> >wrote:
> >> >> >> >
> >> >> >> >> I have two ways that I know of to enable maintenance mode on a
> >> >>host,
> >> >> >>but
> >> >> >> >> it seems like neither one returns a request id, where pretty
> much
> >> >> >>every
> >> >> >> >> other API call that generates a request does return an id. Is
> >> >>this a
> >> >> >> >>bug?
> >> >> >> >>
> >> >> >> >> I'm testing against ambari 1.6.1
> >> >> >> >>
> >> >> >> >> PUT
> >> >> >>
> >> >>>>
> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
> >> >> >> >> {"RequestInfo": {"query": "Hosts/host_name.in(
> >> >> c6404.ambari.apache.org
> >> >> >> )",
> >> >> >> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
> >> >> >> >> {"maintenance_state": "ON"}}}
> >> >> >> >>
> >> >> >> >> Response is a 200 with an empty response body.
> >> >> >> >>
> >> >> >> >> Alternatively:
> >> >> >> >>
> >> >> >> >> PUT
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
> >> >> >> >>04.ambari.apache.org/host_components?fields=HostRoles/state
> >> >> >> >> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
> >> >> >> >> {"HostRoles": {"maintenance_state": "ON"}}}
> >> >> >> >>
> >> >> >> >> Same response. 200 OK, no body.
> >> >> >> >>
> >> >> >> >> Thanks in advance for any help.
> >> >> >> >>
> >> >> >> >> 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.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >--
> >> >> >Thanks,
> >> >> >Dmitry
> >> >> >
> >> >> >--
> >> >> >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.
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Thanks,
> >> >Dmitry
> >> >
> >> >--
> >> >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.
> >>
> >>
> >
> >
> > --
> > Thanks,
> > Dmitry
> >
>
>
>
> --
> Thanks,
> Dmitry
>
> --
> 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,
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.
Re: setting maintenance mode doesn't return a request id
Posted by Dmitry Lysnichenko <dl...@hortonworks.com>.
Also, how about polling
http://vm-0.vm:8080/api/v1/requests?Requests/request_status=IN_PROGRESS
to make sure no request is running before deleting hosts?
On Thu, Aug 21, 2014 at 10:25 PM, Dmitry Lysnichenko <
dlysnichenko@hortonworks.com> wrote:
> I mean that Nagios update request is triggered as a side effect for a
> request to enable MM (so they are two different requests, one
> externally-generated and executed immediately, and one internally-generated
> and executed asynchronously)
>
> Thank you for clarification. The use case you described definitely makes
> sense, I'll talk to other devs regarding that.
>
>
> On Thu, Aug 21, 2014 at 10:14 PM, Greg Hill <gr...@rackspace.com>
> wrote:
>
>> Perhaps I should clarify. This is what I'm trying to do:
>>
>> 1. Set host in maintenance mode
>> 2. Stop all host components on that host
>> 3. Remove all host components
>> 4. Remove host from cluster
>>
>> If I start #2 before #1 has updated nagios, there is potential for nagios
>> to send out down alerts for the components that I'm stopping on purpose.
>> It's probably unlikely, but it is nondeterministic. I'd rather know that
>> the components are no longer being monitored before I start turning them
>> off.
>>
>> I guess I don't see the philosophical difference between this background
>> operation and other background operations. They both show up in the
>> Ambari UI in the same place, so I must not be the only one who doesn't see
>> the distinction. I'm passing in a Request that spawns a background
>> process, so I should get back the Request ID, shouldn't I? What
>> understanding am I missing?
>>
>> Greg
>>
>> On 8/21/14 1:24 PM, "Dmitry Lysnichenko" <dl...@hortonworks.com>
>> wrote:
>>
>> >In this particular case (with a current implementation), you are unlikely
>> >to introduce a race condition since the background operation only sends
>> to
>> >Nagios a list of MM components. So even if you delete some component
>> >(except Nagios) while the request is running, nothing bad is going to
>> >happen.
>> >
>> >If we add a response body for this request, the behavior is going to
>> >become
>> >inconsistent: we will either have or have not a request body depending on
>> >Nagios presence in the cluster. Maybe Siddharth Wagle may comment on
>> this.
>> >
>> >
>> >On Thu, Aug 21, 2014 at 8:53 PM, Greg Hill <gr...@rackspace.com>
>> >wrote:
>> >
>> >> Right, but I need to wait for that nagios update to finish before I
>> >>start
>> >> deleting things or I've introduced a race condition with nagios alerts.
>> >> How do I poll the status on it if I don't get a request id back?
>> >>
>> >> Greg
>> >>
>> >> On 8/21/14 12:47 PM, "Dmitry Lysnichenko" <
>> dlysnichenko@hortonworks.com>
>> >> wrote:
>> >>
>> >> >Hi Greg,
>> >> >
>> >> >Targets are put to MM immediately (during request). The background
>> task
>> >> >only updates Nagios configuration to ignore alerts for MM components.
>> >> >
>> >> >
>> >> >On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill <gr...@rackspace.com>
>> >> >wrote:
>> >> >
>> >> >> I guess I'm confused then. It triggers a background task that takes
>> >>17s
>> >> >> to complete according to the UI, but returns immediately. Is the UI
>> >> >> wrong? It definitely isn't immediate; it has to wait for it to
>> >>update
>> >> >> nagios before it's safe to proceed doing destructive things.
>> >> >>
>> >> >> Greg
>> >> >>
>> >> >> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com>
>> >>wrote:
>> >> >>
>> >> >> >Hi Greg,
>> >> >> >
>> >> >> >A response to a POST request will have a body with the (request id)
>> >> >>only
>> >> >> >if
>> >> >> >the POST request triggers a asynchronous operation and the request
>> >>id
>> >> >>is a
>> >> >> >way of tracking the operation.
>> >> >> >
>> >> >> >Putting a host in Maintenance mode is not an async op, so this is
>> >> >>working
>> >> >> >as expected.
>> >> >> >
>> >> >> >Regards,
>> >> >> >Sid
>> >> >> >
>> >> >> >
>> >> >> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill
>> >><gr...@rackspace.com>
>> >> >> >wrote:
>> >> >> >
>> >> >> >> I have two ways that I know of to enable maintenance mode on a
>> >>host,
>> >> >>but
>> >> >> >> it seems like neither one returns a request id, where pretty much
>> >> >>every
>> >> >> >> other API call that generates a request does return an id. Is
>> >>this a
>> >> >> >>bug?
>> >> >> >>
>> >> >> >> I'm testing against ambari 1.6.1
>> >> >> >>
>> >> >> >> PUT
>> >> >>
>> >>>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
>> >> >> >> {"RequestInfo": {"query": "Hosts/host_name.in(
>> >> c6404.ambari.apache.org
>> >> >> )",
>> >> >> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
>> >> >> >> {"maintenance_state": "ON"}}}
>> >> >> >>
>> >> >> >> Response is a 200 with an empty response body.
>> >> >> >>
>> >> >> >> Alternatively:
>> >> >> >>
>> >> >> >> PUT
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
>> >> >> >>04.ambari.apache.org/host_components?fields=HostRoles/state
>> >> >> >> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
>> >> >> >> {"HostRoles": {"maintenance_state": "ON"}}}
>> >> >> >>
>> >> >> >> Same response. 200 OK, no body.
>> >> >> >>
>> >> >> >> Thanks in advance for any help.
>> >> >> >>
>> >> >> >> 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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >Thanks,
>> >> >Dmitry
>> >> >
>> >> >--
>> >> >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.
>> >>
>> >>
>> >
>> >
>> >--
>> >Thanks,
>> >Dmitry
>> >
>> >--
>> >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.
>>
>>
>
>
> --
> Thanks,
> Dmitry
>
--
Thanks,
Dmitry
--
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.
Re: setting maintenance mode doesn't return a request id
Posted by Dmitry Lysnichenko <dl...@hortonworks.com>.
I mean that Nagios update request is triggered as a side effect for a
request to enable MM (so they are two different requests, one
externally-generated and executed immediately, and one internally-generated
and executed asynchronously)
Thank you for clarification. The use case you described definitely makes
sense, I'll talk to other devs regarding that.
On Thu, Aug 21, 2014 at 10:14 PM, Greg Hill <gr...@rackspace.com> wrote:
> Perhaps I should clarify. This is what I'm trying to do:
>
> 1. Set host in maintenance mode
> 2. Stop all host components on that host
> 3. Remove all host components
> 4. Remove host from cluster
>
> If I start #2 before #1 has updated nagios, there is potential for nagios
> to send out down alerts for the components that I'm stopping on purpose.
> It's probably unlikely, but it is nondeterministic. I'd rather know that
> the components are no longer being monitored before I start turning them
> off.
>
> I guess I don't see the philosophical difference between this background
> operation and other background operations. They both show up in the
> Ambari UI in the same place, so I must not be the only one who doesn't see
> the distinction. I'm passing in a Request that spawns a background
> process, so I should get back the Request ID, shouldn't I? What
> understanding am I missing?
>
> Greg
>
> On 8/21/14 1:24 PM, "Dmitry Lysnichenko" <dl...@hortonworks.com>
> wrote:
>
> >In this particular case (with a current implementation), you are unlikely
> >to introduce a race condition since the background operation only sends to
> >Nagios a list of MM components. So even if you delete some component
> >(except Nagios) while the request is running, nothing bad is going to
> >happen.
> >
> >If we add a response body for this request, the behavior is going to
> >become
> >inconsistent: we will either have or have not a request body depending on
> >Nagios presence in the cluster. Maybe Siddharth Wagle may comment on this.
> >
> >
> >On Thu, Aug 21, 2014 at 8:53 PM, Greg Hill <gr...@rackspace.com>
> >wrote:
> >
> >> Right, but I need to wait for that nagios update to finish before I
> >>start
> >> deleting things or I've introduced a race condition with nagios alerts.
> >> How do I poll the status on it if I don't get a request id back?
> >>
> >> Greg
> >>
> >> On 8/21/14 12:47 PM, "Dmitry Lysnichenko" <dlysnichenko@hortonworks.com
> >
> >> wrote:
> >>
> >> >Hi Greg,
> >> >
> >> >Targets are put to MM immediately (during request). The background task
> >> >only updates Nagios configuration to ignore alerts for MM components.
> >> >
> >> >
> >> >On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill <gr...@rackspace.com>
> >> >wrote:
> >> >
> >> >> I guess I'm confused then. It triggers a background task that takes
> >>17s
> >> >> to complete according to the UI, but returns immediately. Is the UI
> >> >> wrong? It definitely isn't immediate; it has to wait for it to
> >>update
> >> >> nagios before it's safe to proceed doing destructive things.
> >> >>
> >> >> Greg
> >> >>
> >> >> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com>
> >>wrote:
> >> >>
> >> >> >Hi Greg,
> >> >> >
> >> >> >A response to a POST request will have a body with the (request id)
> >> >>only
> >> >> >if
> >> >> >the POST request triggers a asynchronous operation and the request
> >>id
> >> >>is a
> >> >> >way of tracking the operation.
> >> >> >
> >> >> >Putting a host in Maintenance mode is not an async op, so this is
> >> >>working
> >> >> >as expected.
> >> >> >
> >> >> >Regards,
> >> >> >Sid
> >> >> >
> >> >> >
> >> >> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill
> >><gr...@rackspace.com>
> >> >> >wrote:
> >> >> >
> >> >> >> I have two ways that I know of to enable maintenance mode on a
> >>host,
> >> >>but
> >> >> >> it seems like neither one returns a request id, where pretty much
> >> >>every
> >> >> >> other API call that generates a request does return an id. Is
> >>this a
> >> >> >>bug?
> >> >> >>
> >> >> >> I'm testing against ambari 1.6.1
> >> >> >>
> >> >> >> PUT
> >> >>
> >>>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
> >> >> >> {"RequestInfo": {"query": "Hosts/host_name.in(
> >> c6404.ambari.apache.org
> >> >> )",
> >> >> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
> >> >> >> {"maintenance_state": "ON"}}}
> >> >> >>
> >> >> >> Response is a 200 with an empty response body.
> >> >> >>
> >> >> >> Alternatively:
> >> >> >>
> >> >> >> PUT
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
> >> >> >>04.ambari.apache.org/host_components?fields=HostRoles/state
> >> >> >> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
> >> >> >> {"HostRoles": {"maintenance_state": "ON"}}}
> >> >> >>
> >> >> >> Same response. 200 OK, no body.
> >> >> >>
> >> >> >> Thanks in advance for any help.
> >> >> >>
> >> >> >> 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.
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Thanks,
> >> >Dmitry
> >> >
> >> >--
> >> >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.
> >>
> >>
> >
> >
> >--
> >Thanks,
> >Dmitry
> >
> >--
> >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.
>
>
--
Thanks,
Dmitry
--
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.
Re: setting maintenance mode doesn't return a request id
Posted by Greg Hill <gr...@RACKSPACE.COM>.
Perhaps I should clarify. This is what I'm trying to do:
1. Set host in maintenance mode
2. Stop all host components on that host
3. Remove all host components
4. Remove host from cluster
If I start #2 before #1 has updated nagios, there is potential for nagios
to send out down alerts for the components that I'm stopping on purpose.
It's probably unlikely, but it is nondeterministic. I'd rather know that
the components are no longer being monitored before I start turning them
off.
I guess I don't see the philosophical difference between this background
operation and other background operations. They both show up in the
Ambari UI in the same place, so I must not be the only one who doesn't see
the distinction. I'm passing in a Request that spawns a background
process, so I should get back the Request ID, shouldn't I? What
understanding am I missing?
Greg
On 8/21/14 1:24 PM, "Dmitry Lysnichenko" <dl...@hortonworks.com>
wrote:
>In this particular case (with a current implementation), you are unlikely
>to introduce a race condition since the background operation only sends to
>Nagios a list of MM components. So even if you delete some component
>(except Nagios) while the request is running, nothing bad is going to
>happen.
>
>If we add a response body for this request, the behavior is going to
>become
>inconsistent: we will either have or have not a request body depending on
>Nagios presence in the cluster. Maybe Siddharth Wagle may comment on this.
>
>
>On Thu, Aug 21, 2014 at 8:53 PM, Greg Hill <gr...@rackspace.com>
>wrote:
>
>> Right, but I need to wait for that nagios update to finish before I
>>start
>> deleting things or I've introduced a race condition with nagios alerts.
>> How do I poll the status on it if I don't get a request id back?
>>
>> Greg
>>
>> On 8/21/14 12:47 PM, "Dmitry Lysnichenko" <dl...@hortonworks.com>
>> wrote:
>>
>> >Hi Greg,
>> >
>> >Targets are put to MM immediately (during request). The background task
>> >only updates Nagios configuration to ignore alerts for MM components.
>> >
>> >
>> >On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill <gr...@rackspace.com>
>> >wrote:
>> >
>> >> I guess I'm confused then. It triggers a background task that takes
>>17s
>> >> to complete according to the UI, but returns immediately. Is the UI
>> >> wrong? It definitely isn't immediate; it has to wait for it to
>>update
>> >> nagios before it's safe to proceed doing destructive things.
>> >>
>> >> Greg
>> >>
>> >> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com>
>>wrote:
>> >>
>> >> >Hi Greg,
>> >> >
>> >> >A response to a POST request will have a body with the (request id)
>> >>only
>> >> >if
>> >> >the POST request triggers a asynchronous operation and the request
>>id
>> >>is a
>> >> >way of tracking the operation.
>> >> >
>> >> >Putting a host in Maintenance mode is not an async op, so this is
>> >>working
>> >> >as expected.
>> >> >
>> >> >Regards,
>> >> >Sid
>> >> >
>> >> >
>> >> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill
>><gr...@rackspace.com>
>> >> >wrote:
>> >> >
>> >> >> I have two ways that I know of to enable maintenance mode on a
>>host,
>> >>but
>> >> >> it seems like neither one returns a request id, where pretty much
>> >>every
>> >> >> other API call that generates a request does return an id. Is
>>this a
>> >> >>bug?
>> >> >>
>> >> >> I'm testing against ambari 1.6.1
>> >> >>
>> >> >> PUT
>> >>
>>>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
>> >> >> {"RequestInfo": {"query": "Hosts/host_name.in(
>> c6404.ambari.apache.org
>> >> )",
>> >> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
>> >> >> {"maintenance_state": "ON"}}}
>> >> >>
>> >> >> Response is a 200 with an empty response body.
>> >> >>
>> >> >> Alternatively:
>> >> >>
>> >> >> PUT
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
>> >> >>04.ambari.apache.org/host_components?fields=HostRoles/state
>> >> >> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
>> >> >> {"HostRoles": {"maintenance_state": "ON"}}}
>> >> >>
>> >> >> Same response. 200 OK, no body.
>> >> >>
>> >> >> Thanks in advance for any help.
>> >> >>
>> >> >> 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.
>> >>
>> >>
>> >
>> >
>> >--
>> >Thanks,
>> >Dmitry
>> >
>> >--
>> >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.
>>
>>
>
>
>--
>Thanks,
>Dmitry
>
>--
>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.
Re: setting maintenance mode doesn't return a request id
Posted by Dmitry Lysnichenko <dl...@hortonworks.com>.
In this particular case (with a current implementation), you are unlikely
to introduce a race condition since the background operation only sends to
Nagios a list of MM components. So even if you delete some component
(except Nagios) while the request is running, nothing bad is going to
happen.
If we add a response body for this request, the behavior is going to become
inconsistent: we will either have or have not a request body depending on
Nagios presence in the cluster. Maybe Siddharth Wagle may comment on this.
On Thu, Aug 21, 2014 at 8:53 PM, Greg Hill <gr...@rackspace.com> wrote:
> Right, but I need to wait for that nagios update to finish before I start
> deleting things or I've introduced a race condition with nagios alerts.
> How do I poll the status on it if I don't get a request id back?
>
> Greg
>
> On 8/21/14 12:47 PM, "Dmitry Lysnichenko" <dl...@hortonworks.com>
> wrote:
>
> >Hi Greg,
> >
> >Targets are put to MM immediately (during request). The background task
> >only updates Nagios configuration to ignore alerts for MM components.
> >
> >
> >On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill <gr...@rackspace.com>
> >wrote:
> >
> >> I guess I'm confused then. It triggers a background task that takes 17s
> >> to complete according to the UI, but returns immediately. Is the UI
> >> wrong? It definitely isn't immediate; it has to wait for it to update
> >> nagios before it's safe to proceed doing destructive things.
> >>
> >> Greg
> >>
> >> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com> wrote:
> >>
> >> >Hi Greg,
> >> >
> >> >A response to a POST request will have a body with the (request id)
> >>only
> >> >if
> >> >the POST request triggers a asynchronous operation and the request id
> >>is a
> >> >way of tracking the operation.
> >> >
> >> >Putting a host in Maintenance mode is not an async op, so this is
> >>working
> >> >as expected.
> >> >
> >> >Regards,
> >> >Sid
> >> >
> >> >
> >> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill <gr...@rackspace.com>
> >> >wrote:
> >> >
> >> >> I have two ways that I know of to enable maintenance mode on a host,
> >>but
> >> >> it seems like neither one returns a request id, where pretty much
> >>every
> >> >> other API call that generates a request does return an id. Is this a
> >> >>bug?
> >> >>
> >> >> I'm testing against ambari 1.6.1
> >> >>
> >> >> PUT
> >> >>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
> >> >> {"RequestInfo": {"query": "Hosts/host_name.in(
> c6404.ambari.apache.org
> >> )",
> >> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
> >> >> {"maintenance_state": "ON"}}}
> >> >>
> >> >> Response is a 200 with an empty response body.
> >> >>
> >> >> Alternatively:
> >> >>
> >> >> PUT
> >> >>
> >> >>
> >>
> >>
> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
> >> >>04.ambari.apache.org/host_components?fields=HostRoles/state
> >> >> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
> >> >> {"HostRoles": {"maintenance_state": "ON"}}}
> >> >>
> >> >> Same response. 200 OK, no body.
> >> >>
> >> >> Thanks in advance for any help.
> >> >>
> >> >> 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.
> >>
> >>
> >
> >
> >--
> >Thanks,
> >Dmitry
> >
> >--
> >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.
>
>
--
Thanks,
Dmitry
--
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.
Re: setting maintenance mode doesn't return a request id
Posted by Greg Hill <gr...@RACKSPACE.COM>.
Right, but I need to wait for that nagios update to finish before I start
deleting things or I've introduced a race condition with nagios alerts.
How do I poll the status on it if I don't get a request id back?
Greg
On 8/21/14 12:47 PM, "Dmitry Lysnichenko" <dl...@hortonworks.com>
wrote:
>Hi Greg,
>
>Targets are put to MM immediately (during request). The background task
>only updates Nagios configuration to ignore alerts for MM components.
>
>
>On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill <gr...@rackspace.com>
>wrote:
>
>> I guess I'm confused then. It triggers a background task that takes 17s
>> to complete according to the UI, but returns immediately. Is the UI
>> wrong? It definitely isn't immediate; it has to wait for it to update
>> nagios before it's safe to proceed doing destructive things.
>>
>> Greg
>>
>> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com> wrote:
>>
>> >Hi Greg,
>> >
>> >A response to a POST request will have a body with the (request id)
>>only
>> >if
>> >the POST request triggers a asynchronous operation and the request id
>>is a
>> >way of tracking the operation.
>> >
>> >Putting a host in Maintenance mode is not an async op, so this is
>>working
>> >as expected.
>> >
>> >Regards,
>> >Sid
>> >
>> >
>> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill <gr...@rackspace.com>
>> >wrote:
>> >
>> >> I have two ways that I know of to enable maintenance mode on a host,
>>but
>> >> it seems like neither one returns a request id, where pretty much
>>every
>> >> other API call that generates a request does return an id. Is this a
>> >>bug?
>> >>
>> >> I'm testing against ambari 1.6.1
>> >>
>> >> PUT
>> >>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
>> >> {"RequestInfo": {"query": "Hosts/host_name.in(c6404.ambari.apache.org
>> )",
>> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
>> >> {"maintenance_state": "ON"}}}
>> >>
>> >> Response is a 200 with an empty response body.
>> >>
>> >> Alternatively:
>> >>
>> >> PUT
>> >>
>> >>
>>
>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
>> >>04.ambari.apache.org/host_components?fields=HostRoles/state
>> >> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
>> >> {"HostRoles": {"maintenance_state": "ON"}}}
>> >>
>> >> Same response. 200 OK, no body.
>> >>
>> >> Thanks in advance for any help.
>> >>
>> >> 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.
>>
>>
>
>
>--
>Thanks,
>Dmitry
>
>--
>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.
Re: setting maintenance mode doesn't return a request id
Posted by Dmitry Lysnichenko <dl...@hortonworks.com>.
Hi Greg,
Targets are put to MM immediately (during request). The background task
only updates Nagios configuration to ignore alerts for MM components.
On Thu, Aug 21, 2014 at 8:41 PM, Greg Hill <gr...@rackspace.com> wrote:
> I guess I'm confused then. It triggers a background task that takes 17s
> to complete according to the UI, but returns immediately. Is the UI
> wrong? It definitely isn't immediate; it has to wait for it to update
> nagios before it's safe to proceed doing destructive things.
>
> Greg
>
> On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com> wrote:
>
> >Hi Greg,
> >
> >A response to a POST request will have a body with the (request id) only
> >if
> >the POST request triggers a asynchronous operation and the request id is a
> >way of tracking the operation.
> >
> >Putting a host in Maintenance mode is not an async op, so this is working
> >as expected.
> >
> >Regards,
> >Sid
> >
> >
> >On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill <gr...@rackspace.com>
> >wrote:
> >
> >> I have two ways that I know of to enable maintenance mode on a host, but
> >> it seems like neither one returns a request id, where pretty much every
> >> other API call that generates a request does return an id. Is this a
> >>bug?
> >>
> >> I'm testing against ambari 1.6.1
> >>
> >> PUT
> >>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
> >> {"RequestInfo": {"query": "Hosts/host_name.in(c6404.ambari.apache.org
> )",
> >> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
> >> {"maintenance_state": "ON"}}}
> >>
> >> Response is a 200 with an empty response body.
> >>
> >> Alternatively:
> >>
> >> PUT
> >>
> >>
> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
> >>04.ambari.apache.org/host_components?fields=HostRoles/state
> >> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
> >> {"HostRoles": {"maintenance_state": "ON"}}}
> >>
> >> Same response. 200 OK, no body.
> >>
> >> Thanks in advance for any help.
> >>
> >> 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.
>
>
--
Thanks,
Dmitry
--
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.
Re: setting maintenance mode doesn't return a request id
Posted by Greg Hill <gr...@RACKSPACE.COM>.
I guess I'm confused then. It triggers a background task that takes 17s
to complete according to the UI, but returns immediately. Is the UI
wrong? It definitely isn't immediate; it has to wait for it to update
nagios before it's safe to proceed doing destructive things.
Greg
On 8/21/14 12:24 PM, "Siddharth Wagle" <sw...@hortonworks.com> wrote:
>Hi Greg,
>
>A response to a POST request will have a body with the (request id) only
>if
>the POST request triggers a asynchronous operation and the request id is a
>way of tracking the operation.
>
>Putting a host in Maintenance mode is not an async op, so this is working
>as expected.
>
>Regards,
>Sid
>
>
>On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill <gr...@rackspace.com>
>wrote:
>
>> I have two ways that I know of to enable maintenance mode on a host, but
>> it seems like neither one returns a request id, where pretty much every
>> other API call that generates a request does return an id. Is this a
>>bug?
>>
>> I'm testing against ambari 1.6.1
>>
>> PUT
>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
>> {"RequestInfo": {"query": "Hosts/host_name.in(c6404.ambari.apache.org)",
>> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
>> {"maintenance_state": "ON"}}}
>>
>> Response is a 200 with an empty response body.
>>
>> Alternatively:
>>
>> PUT
>>
>>http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c64
>>04.ambari.apache.org/host_components?fields=HostRoles/state
>> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
>> {"HostRoles": {"maintenance_state": "ON"}}}
>>
>> Same response. 200 OK, no body.
>>
>> Thanks in advance for any help.
>>
>> 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.
Re: setting maintenance mode doesn't return a request id
Posted by Siddharth Wagle <sw...@hortonworks.com>.
Hi Greg,
A response to a POST request will have a body with the (request id) only if
the POST request triggers a asynchronous operation and the request id is a
way of tracking the operation.
Putting a host in Maintenance mode is not an async op, so this is working
as expected.
Regards,
Sid
On Thu, Aug 21, 2014 at 10:17 AM, Greg Hill <gr...@rackspace.com> wrote:
> I have two ways that I know of to enable maintenance mode on a host, but
> it seems like neither one returns a request id, where pretty much every
> other API call that generates a request does return an id. Is this a bug?
>
> I'm testing against ambari 1.6.1
>
> PUT http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts
> {"RequestInfo": {"query": "Hosts/host_name.in(c6404.ambari.apache.org)",
> "context": "Start Maintenance Mode"}, "Body": {"Hosts":
> {"maintenance_state": "ON"}}}
>
> Response is a 200 with an empty response body.
>
> Alternatively:
>
> PUT
> http://c6401.ambari.apache.org:8080/api/v1/clusters/testcluster/hosts/c6404.ambari.apache.org/host_components?fields=HostRoles/state
> {"RequestInfo": {"context": "Start Maintenance Mode"}, "Body":
> {"HostRoles": {"maintenance_state": "ON"}}}
>
> Same response. 200 OK, no body.
>
> Thanks in advance for any help.
>
> 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.