> On Dec 23, 2015, at 6:27 PM, Manoj Samel <manojsamelt...@gmail.com> wrote: > > Jon, as to your last comment - > > As I understand, the idea of pushing slider registry to more general yarn > registry was to make it easier for clients of application to query, without > going through slider (URIs) at all. Most client would care about info for > live application. If client query on ZK registry can't tell whether the > application is live, then its not clear what is the value of registry for > clients of the application- there has to be some path in registry that is > tied to liveliness of the application.
As Steve indicated, there is a patch that will be merged post the next release that does, in fact, purge the repository entries during a stop (SLIDER-1017). That should address the concern about a mismatch of availability of information between resources (ZK vs AM). I think the registry being moved to Yarn was more an effort to make its facilities available as a resource for all yarn applications rather than slider specifically. But I would also agree that its utility as a “liveness” indicator is enhanced by this fix. > > If slider wants to keep the configurations of stopped applications around, > would some other ZK path or may be HDFS be a store for it ? > > Thoughts? > > Manoj > > > > On Wed, Dec 23, 2015 at 12:36 PM, Steve Loughran <ste...@hortonworks.com> > wrote: > >> there's a patch up to do the deletion (best effort) when things get taken >> down...I plan to pull it in once we've got this 0.90 release out >> >>> On 23 Dec 2015, at 20:21, Jon Maron <jma...@hortonworks.com> wrote: >>> >>>> >>>> On Dec 23, 2015, at 3:13 PM, Manoj Samel <manojsamelt...@gmail.com> >> wrote: >>>> >>>> Thanks Jon, >>>> >>>> I thought the ZK registry was to reflect the live information about the >>>> running application (i.e. I expected it to fail with no nodes found when >>>> app is not running) but that does not seems to be the intent. >>>> >>>> On the other hand, >>>> http:// >> <slider-am-host>:1025/ws/v1/slider/publisher/slider/componentinstancedata >>>> < >> http://ip-10-222-0-38.us-west-2.compute.internal:1025/ws/v1/slider/publisher/slider/componentinstancedata >>> >>>> gives >>>> info only when app is running. Should the clients be quering this URL >>>> rather than ZK nodes to if they expect to get info only when app is >> running >>>> ? >>> >>> I would say that, in general, to get information about the live >> instances it is best to leverage the URIs. They generally provide access >> to in-memory or registry based information. >>> >>>> >>>> Thanks, >>>> >>>> Manoj >>>> >>>> On Wed, Dec 23, 2015 at 11:12 AM, Jon Maron <jma...@hortonworks.com> >> wrote: >>>> >>>>> >>>>>> On Dec 23, 2015, at 2:03 PM, Manoj Samel <manojsamelt...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Setup - slider version .80, secure hadoop cluster, registry enabled >> with >>>>>> security >>>>>> >>>>>> Noticed using *** zookeeper client (zkCli.sh) *** that when slider >>>>>> application is stopped, the registry entries in >>>>>> zookeeper >> /registry/users/xxx/services/org-apache-slider/abc/components >>>>> do >>>>>> not get deleted. However, they do get updated when application is >> started >>>>>> again and new container IDs get allocated. In this case, the >>>>>> components/containers_ do reflect new container IDs. Also noticed >> that ZK >>>>>> registry entries do get deleted if "destroy" applications is done. >>>>>> >>>>>> Is this expected behavior ? Shouldn't the ZK entries be deleted when >>>>>> application and its containers are not present after application is >>>>> stopped >>>>>> ? >>>>> >>>>> Not exactly. You could think of start/stop as thaw/freeze (their >> actual >>>>> previous incarnation). The idea is that a “stop” terminates the >>>>> application instance but maintains the configuration so that another >>>>> instance can be started based on the same configuration. You probably >>>>> could also think of the ZK config as the “class definition” and the >> actual >>>>> launched instance as the “Object”. >>>>> >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> Manoj >> >>
