ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Lysnichenko <dlysniche...@hortonworks.com>
Subject Re: setting maintenance mode doesn't return a request id
Date Thu, 21 Aug 2014 19:25:50 GMT
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 <greg.hill@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" <dlysnichenko@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 <greg.hill@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" <swagle@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
> >><greg.hill@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message