Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A9AA9200C53 for ; Tue, 28 Mar 2017 05:17:33 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A80F7160B99; Tue, 28 Mar 2017 03:17:33 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 502A5160B85 for ; Tue, 28 Mar 2017 05:17:32 +0200 (CEST) Received: (qmail 38657 invoked by uid 500); 28 Mar 2017 03:17:31 -0000 Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@oodt.apache.org Delivered-To: mailing list dev@oodt.apache.org Received: (qmail 38644 invoked by uid 99); 28 Mar 2017 03:17:31 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Mar 2017 03:17:31 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 89C8DC0421 for ; Tue, 28 Mar 2017 03:17:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.98 X-Spam-Level: * X-Spam-Status: No, score=1.98 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=cse-mrt-ac-lk.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id cwVv9LKZBWmb for ; Tue, 28 Mar 2017 03:17:27 +0000 (UTC) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com [209.85.214.43]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id A271D5F253 for ; Tue, 28 Mar 2017 03:17:26 +0000 (UTC) Received: by mail-it0-f43.google.com with SMTP id 190so5157494itm.0 for ; Mon, 27 Mar 2017 20:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cse-mrt-ac-lk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RHjqNX71mO3P/fSfDKEjRMBA3VgoqGOpR7YtCVOXhL4=; b=iucu3bmGojv2foXTx5KN9ZCIActnNSXeHMT3jOhbP4Mudy1cCyutKq1lmgCFRShTy3 4JttEvRyn9IvqedJVX6ZoQQklQCJRmsEae2z3/2TEKs5zbi/GgTdtE7ETmYqwang26H6 KIVi+OMY0jmDEHySPZlTZCVtECEAL629nBZvNmBMnZetqEDUWSj5Arg6gtwHcz4Sif0b dzYQCWdGrjKIejp0PftBtXDhBQI3PIY/Uoo6wB+A3Dda4Fh55a2CB5Qsm2svaMh7ROny h+dzZj7ujKp7+k1RgLyAnDOUZIRRpnWce+NCCjWkpAPqP8LZ7d2NC5eL9jKtMO4TyLAV tAeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=RHjqNX71mO3P/fSfDKEjRMBA3VgoqGOpR7YtCVOXhL4=; b=sgDXJsj53sbMnNNIOtHsjrgDC1Q0sV0vcY+rzxvO6tBnsc2gevrFsuzm0uE6TeewYL C8b1msI48R/Kj7LeRXQKf/86uXN3WrS6/SwWaRehOfcWroqu7FI5fiztBey5lBwVD660 q+CxpPpwCe3WjXq9X7vP0/YV45RqTSph3a2o4pVrxrxtZs9xaRD6GVN6PJxxNX6F0JAL mHtXlogjc9jp21rUYVSEdjWilFuQFL7WDXKvnFcClLi3Ey41RX7flhBwaSpjihHIe2za 5gZeIVWniuY6+2M7tX5Dr/Rk8y0J0GJFG1BLWvg4NZ7QbBHvzj4yFLnCSAJBLYQ62Yhb rMuQ== X-Gm-Message-State: AFeK/H1cYuosRCmGKrsQ9MDH/5zDeT5wjpDBSRgaFjMNw1goJ6uim7LgxdkLFpkADvZZgCTvAgQ/+v1YchxezB1y X-Received: by 10.36.78.201 with SMTP id r192mr12520510ita.96.1490671045593; Mon, 27 Mar 2017 20:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.85.198 with HTTP; Mon, 27 Mar 2017 20:16:45 -0700 (PDT) In-Reply-To: References: From: Imesha Sudasingha Date: Tue, 28 Mar 2017 08:46:45 +0530 Message-ID: Subject: Re: GSoC 2017 - Rework OODT Configuration to make use of Zookeeper To: dev@oodt.apache.org Content-Type: multipart/alternative; boundary=001a1143d3962686d4054bc1e65f archived-at: Tue, 28 Mar 2017 03:17:33 -0000 --001a1143d3962686d4054bc1e65f Content-Type: text/plain; charset=UTF-8 Thanks a lot Tom! Kind Regards, *Imesha Sudasingha* Undergraduate of Department of Computer Science and Engineering, University of Moratuwa, Sri Lanka. On 28 March 2017 at 08:40, Tom Barber wrote: > Thanks Imesha > > I shall check it tomorrow and get back to you ASAP. > > Tom > > On Tue, Mar 28, 2017 at 2:33 AM, Imesha Sudasingha < > imesha.13@cse.mrt.ac.lk> > wrote: > > > Hi Tom, > > > > As you suggested, I have created a copy of my proposal at [1] and shared > > with comment permissions. It will be a great help if you can review it > > sooner and provide a kind feedback. > > > > Thank you! > > > > [1] > > https://docs.google.com/document/d/1bnFEVViCwMACHJRB1OiYZ- > > GAywCNJRxrUJPpHttpgpE/edit?usp=sharing > > > > Kind Regards, > > *Imesha Sudasingha* > > Undergraduate of Department of Computer Science and Engineering, > > University of Moratuwa, > > Sri Lanka. > > > > > > > > > > > > > On 28 March 2017 at 01:13, Tom Barber wrote: > > > > > Hi Imesha > > > > > > I'm trying to figure out if/how I can get access to it on the > dashboard. > > In > > > the mean time if you want to pastebin it, chuck it in a word doc, or > > > something completely different I'd be happy to take a look. > > > > > > Tom > > > > > > On Sun, Mar 26, 2017 at 3:09 PM, Imesha Sudasingha < > > > imesha.13@cse.mrt.ac.lk> > > > wrote: > > > > > > > Hi Tom, > > > > > > > > Did you get a chance to look at my proposal? > > > > > > > > Kind Regards, > > > > *Imesha Sudasingha* > > > > Undergraduate of Department of Computer Science and Engineering, > > > > University of Moratuwa, > > > > Sri Lanka. > > > > > > > > < > > https://github.com/IMS94 > > > > > > > > > > > > > > > > > > > > On 23 March 2017 at 10:40, Imesha Sudasingha < > imesha.13@cse.mrt.ac.lk> > > > > wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > I have written a draft proposal and shared it with the Apache > > Software > > > > > Foundation through the GSoC dashboard. If you get a chance, can you > > > > please > > > > > review it and let me know what are the improvements required to be > > > made. > > > > > > > > > > Thanks in advance! > > > > > > > > > > Kind Regards, > > > > > *Imesha Sudasingha* > > > > > Undergraduate of Department of Computer Science and Engineering, > > > > > University of Moratuwa, > > > > > Sri Lanka. > > > > > > > > > > < > > > https://github.com/IMS94 > > > > > > > > > > > > > > > > > > > > > > > > > On 22 March 2017 at 14:36, Imesha Sudasingha < > > imesha.13@cse.mrt.ac.lk> > > > > > wrote: > > > > > > > > > >> Hi Tom, > > > > >> > > > > >> I think I had missed your point previously. I was referring to > just > > > > >> storing the configuration of different components in different > > ZNodes > > > > and > > > > >> querying them later. Then I understood that we also need to have > > > > >> inheritance at zookeeper level in order to make it easy to > configure > > > > OODT > > > > >> clusters as you have mentioned in the issue [1]. To configure > > clusters > > > > of > > > > >> OODT components with minimum configuration, I will have to review > my > > > > design > > > > >> again and make a lot of improvements. For example, I have to think > > > > about a > > > > >> way to store configuration in zookeeper with minimum duplications > > and > > > > give > > > > >> components enough flexibility to initialize with no or minimum > > manual > > > > >> configuration. > > > > >> > > > > >> Since I have to submit the GSoC proposal before 3rd of April, I > > think > > > > >> that I won't have enough time to review the design and make the > > > > necessary > > > > >> improvements before that. Will that negatively affect the > > possibility > > > > of me > > > > >> being able to work on this project for GSoC 2017? Please let me > know > > > you > > > > >> opinion. > > > > >> > > > > >> Thank you! > > > > >> > > > > >> [1] https://issues.apache.org/jira/browse/OODT-945 > > > > >> > > > > >> Kind Regards, > > > > >> *Imesha Sudasingha* > > > > >> Undergraduate of Department of Computer Science and Engineering, > > > > >> University of Moratuwa, > > > > >> Sri Lanka. > > > > >> > > > > >> < > > > > https://github.com/IMS94> > > > > >> > > > > >> > > > > >> > > > > >> On 21 March 2017 at 10:52, Imesha Sudasingha < > > imesha.13@cse.mrt.ac.lk > > > > > > > > >> wrote: > > > > >> > > > > >>> Hi Tom, > > > > >>> > > > > >>> Sorry for the late reply. Zookeeper is just providing an ZNode > > > > >>> structure, which can be considered as a tree where a node is > > accessed > > > > as > > > > >>> directories. For example, in [1] the file manager properties of > the > > > > >>> instance with name "*node1*" is stored at the ZPath (Path to that > > > > >>> ZNode) "*/oodt/node1/file-mgr/filemgr.properties*". > > > > >>> > > > > >>> Therefore, my idea is that we can make such directories (ZPaths) > > per > > > > >>> each instance in our cluster (ex: */oodt/node1 for instance > > "node1"*, > > > > */oodt/node2 > > > > >>> for instance "node2"* and so on). Then inside each such path > > > (assigned > > > > >>> per node), we will have separate ZNodes for each component. For > > > > example, in > > > > >>> */oodt/node1* we will have an ZNode /oodt/node1/file-mgr which > > stores > > > > >>> the configurations of file manager of node1. Similarly, an ZNode > > > > >>> /oodt/node1/res-mgr will store the configuration of the resource > > > > manager of > > > > >>> node1. > > > > >>> > > > > >>> Hope you got the idea. Since zookeeper is not some kind of a > graph > > > > >>> database, I couldn't think of a method to keep inheritance among > > > > >>> configuration at Zookeeper's side. However, the design I suggest > > will > > > > store > > > > >>> the configuration independently and will allow the > users/developers > > > to > > > > >>> query those configuration. Therefore in my opinion, we should let > > the > > > > >>> developer to compare the configuration and make decisions. This > > way, > > > > we can > > > > >>> allow this distributed configuration manager to manage > > configuration > > > > of any > > > > >>> current component or any upcoming component making it more > > > extend-able. > > > > >>> > > > > >>> Can you let me know what do you think of it? > > > > >>> > > > > >>> Thank you! > > > > >>> > > > > >>> [1] https://drive.google.com/open?id= > 0B415Bnipaf1lNThKYXZMN3pFemc > > > > >>> > > > > >>> Kind Regards, > > > > >>> *Imesha Sudasingha* > > > > >>> Undergraduate of Department of Computer Science and Engineering, > > > > >>> University of Moratuwa, > > > > >>> Sri Lanka. > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> On 20 March 2017 at 05:02, Tom Barber > > > wrote: > > > > >>> > > > > >>>> Hi Imesha > > > > >>>> > > > > >>>> Sorry for the delay, I've been travelling and only just got > myself > > > > >>>> through > > > > >>>> my backlog. > > > > >>>> > > > > >>>> The overall design looks good. I was also thinking it would make > > > sense > > > > >>>> if > > > > >>>> possible to have some form of inheritance in the config. So, for > > > > >>>> example, > > > > >>>> if you have 5 file managers, and they all share the same config > > > > except a > > > > >>>> base url or whatever, it would make sense to have a single set > of > > > > >>>> configs > > > > >>>> and then individual overrides for configs that change. (My > > knowledge > > > > of > > > > >>>> Zookeeper isn't great, I'm assuming something along these lines > is > > > > >>>> possible). > > > > >>>> > > > > >>>> It would also make sense, I think to register this stuff with > the > > > > >>>> resource > > > > >>>> manager, but I'm not sure how that integration would work quite > > yet, > > > > so > > > > >>>> we'll need to figure that one out. > > > > >>>> > > > > >>>> Let me know if you have any questions about the above. > > > > >>>> > > > > >>>> Tom > > > > >>>> > > > > >>>> > > > > >>>> On Sat, Mar 18, 2017 at 12:39 PM, Imesha Sudasingha < > > > > >>>> imesha.13@cse.mrt.ac.lk > > > > >>>> > wrote: > > > > >>>> > > > > >>>> > Hi Tom, > > > > >>>> > > > > > >>>> > What do you think of the design? Do you agree on implementing > > this > > > > >>>> > configuration management section in a separate module? > > > > >>>> > > > > > >>>> > I was thinking on starting on the implementation as a proof of > > > > >>>> concept. Can > > > > >>>> > you give me your kind feedback before I start on that? > > > > >>>> > > > > > >>>> > Thank you! > > > > >>>> > > > > > >>>> > Kind Regards, > > > > >>>> > *Imesha Sudasingha* > > > > >>>> > Undergraduate of Department of Computer Science and > > Engineering, > > > > >>>> > University of Moratuwa, > > > > >>>> > Sri Lanka. > > > > >>>> > > > > > >>>> > < > > > > >>>> https://github.com/IMS94> > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > On 16 March 2017 at 17:51, Imesha Sudasingha < > > > > imesha.13@cse.mrt.ac.lk > > > > >>>> > > > > > >>>> > wrote: > > > > >>>> > > > > > >>>> > > Hi Tom, > > > > >>>> > > > > > > >>>> > > Thanks for the quick reply. I came up with a small design > [1]. > > > > >>>> > > > > > > >>>> > > What I suggest is a separate module for configuration > > > management, > > > > >>>> which > > > > >>>> > > can be extended in future and used by many components as > well. > > > > >>>> > > > > > > >>>> > > As shown in the design [1], File Manager (or any component > > that > > > is > > > > >>>> > willing > > > > >>>> > > to have this extended functionality of distributed > > configuration > > > > >>>> > > management) will have an instance of *ConfigurationManager* > > > which > > > > >>>> is an > > > > >>>> > > interface defined to load configuration (specifically, > > > .properties > > > > >>>> files) > > > > >>>> > > and get configurations of each running instance of the same > > > > >>>> component (If > > > > >>>> > > distributed configuration management is enabled, this will > > > return > > > > >>>> the > > > > >>>> > > configuration of all the other instances). > > > > >>>> > > > > > > >>>> > > There will be two implementing classes of that interface, > > > > >>>> > > *StandaloneConfigurationManager* and > > > > *DistributedConfigurationManag > > > > >>>> er.* > > > > >>>> > As > > > > >>>> > > the name implies, standalone configuration manager is to be > > used > > > > if > > > > >>>> the > > > > >>>> > > users do not intend to used distributed configuration > > > management. > > > > >>>> Also > > > > >>>> > this > > > > >>>> > > will be same as the current mechanism of configuration > > > management. > > > > >>>> Then > > > > >>>> > the > > > > >>>> > > distributed configuration manager will be the implementation > > > using > > > > >>>> > > Zookeeper. > > > > >>>> > > > > > > >>>> > > At zookeeper level, we will need to have a proper naming > > > mechanism > > > > >>>> and a > > > > >>>> > > structure to store configuration. For example,* > > > > >>>> > > /${nodeName}/${componentName}/{$configFileName}* will be > the > > > > place > > > > >>>> where > > > > >>>> > > the configuration file contents will be stored. > > *getFile(String > > > > >>>> fileName) > > > > >>>> > > and getFiles(String directiryName)* of *NodeConfiguration* > > class > > > > >>>> will > > > > >>>> > > return the content of the configuration files and > > configuration > > > > >>>> > directories > > > > >>>> > > respectively. I have demonstrated the ZNode structre I'm > > > expecting > > > > >>>> to > > > > >>>> > > design in [2] > > > > >>>> > > > > > > >>>> > > Please note that this is just a very high level overview of > my > > > > >>>> design and > > > > >>>> > > the real difficulty of implementation comes when testing > this > > > and > > > > >>>> > > addressing the edge cases of zookeeper. Also, I have only > > added > > > > few > > > > >>>> > methods > > > > >>>> > > that came to my mind to the *ConfigurationManager* > interface. > > If > > > > >>>> you find > > > > >>>> > > any fault in this design or have a better design in mind > > please > > > > let > > > > >>>> me > > > > >>>> > know > > > > >>>> > > so that I can optimize this design and do my best to come up > > > with > > > > >>>> the > > > > >>>> > best > > > > >>>> > > possible solution. > > > > >>>> > > > > > > >>>> > > Thank you! > > > > >>>> > > > > > > >>>> > > [1] https://drive.google.com/open?id= > > > 0B415Bnipaf1ldnV1dWt4VVVLam8 > > > > >>>> > > [2] https://drive.google.com/open?id= > > > 0B415Bnipaf1lNThKYXZMN3pFemc > > > > >>>> > > > > > > >>>> > > Kind Regards, > > > > >>>> > > *Imesha Sudasingha* > > > > >>>> > > Undergraduate of Department of Computer Science and > > > Engineering, > > > > >>>> > > University of Moratuwa, > > > > >>>> > > Sri Lanka. > > > > >>>> > > > > > > >>>> > > < > > > > >>>> https://github.com/IMS94 > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > On 16 March 2017 at 16:55, Tom Barber < > > tom.barber@meteorite.bi> > > > > >>>> wrote: > > > > >>>> > > > > > > >>>> > >> Hi Imesha, > > > > >>>> > >> > > > > >>>> > >> Basically, just allowing the dynamic registration of file > > > > managers > > > > >>>> so > > > > >>>> > that > > > > >>>> > >> new ones can come and go. > > > > >>>> > >> > > > > >>>> > >> Tom > > > > >>>> > >> > > > > >>>> > >> On Thu, Mar 16, 2017 at 10:00 AM, Imesha Sudasingha < > > > > >>>> > >> imesha.13@cse.mrt.ac.lk > > > > >>>> > >> > wrote: > > > > >>>> > >> > > > > >>>> > >> > Hi Tom, > > > > >>>> > >> > > > > > >>>> > >> > Need a small clarification. In the last reply, you > > mentioned > > > > >>>> that file > > > > >>>> > >> > managers may be designed to be *transient. *What do you > > mean > > > by > > > > >>>> that? > > > > >>>> > A > > > > >>>> > >> > quick response would really help me as I'm trying to come > > up > > > > >>>> with a > > > > >>>> > >> design. > > > > >>>> > >> > > > > > >>>> > >> > Thank you! > > > > >>>> > >> > > > > > >>>> > >> > *Imesha Sudasingha* > > > > >>>> > >> > Undergraduate of Department of Computer Science and > > > > Engineering, > > > > >>>> > >> > University of Moratuwa, > > > > >>>> > >> > Sri Lanka. > > > > >>>> > >> > > > > > >>>> > >> > < > > > > >>>> > >> https://github.com/IMS94> > > > > >>>> > >> > sudasingha> > > > > >>>> > >> > > > > > >>>> > >> > > > > > >>>> > >> > On 13 March 2017 at 22:03, Imesha Sudasingha < > > > > >>>> imesha.13@cse.mrt.ac.lk > > > > >>>> > > > > > > >>>> > >> > wrote: > > > > >>>> > >> > > > > > >>>> > >> > > Hi Tom, > > > > >>>> > >> > > > > > > >>>> > >> > > Thanks for the clarification. It really helped a lot to > > > fill > > > > >>>> most of > > > > >>>> > >> the > > > > >>>> > >> > > gaps I had unanswered. I have a draft design in my mind > > and > > > > >>>> will > > > > >>>> > post > > > > >>>> > >> for > > > > >>>> > >> > > your review with details soon. > > > > >>>> > >> > > > > > > >>>> > >> > > As for my current understanding, my task is to > implement > > a > > > > >>>> mechanism > > > > >>>> > >> to > > > > >>>> > >> > > switch/chose configuration mechanism (between local > files > > > and > > > > >>>> > zookeer > > > > >>>> > >> for > > > > >>>> > >> > > the moment) and then allow APIs to query those > mechanisms > > > (in > > > > >>>> the > > > > >>>> > >> > zookeeper > > > > >>>> > >> > > scenario) for future use (For File Managers to know > about > > > > other > > > > >>>> > >> instances > > > > >>>> > >> > > and make decisions accordingly). That include > > > > synchronization, > > > > >>>> > >> fetching > > > > >>>> > >> > > configuration from zookeeper if an instance go down and > > > come > > > > >>>> again > > > > >>>> > >> and so > > > > >>>> > >> > > on. Am I correct? > > > > >>>> > >> > > > > > > >>>> > >> > > I will try to come up with the design I mentioned, so > > that > > > > >>>> both of > > > > >>>> > us > > > > >>>> > >> can > > > > >>>> > >> > > discuss more about the improvements and requirements > > soon. > > > > >>>> > >> > > > > > > >>>> > >> > > Thank you for the support! > > > > >>>> > >> > > > > > > >>>> > >> > > Kind Regards, > > > > >>>> > >> > > *Imesha Sudasingha* > > > > >>>> > >> > > Undergraduate of Department of Computer Science and > > > > >>>> Engineering, > > > > >>>> > >> > > University of Moratuwa, > > > > >>>> > >> > > Sri Lanka. > > > > >>>> > >> > > > > > > >>>> > >> > > < > > > > >>>> > >> https://github.com/IMS94 > > > > >>>> > >> > > > > > > >>>> > >> > > > sudasingha> > > > > >>>> > >> > > > > > > >>>> > >> > > > > > > >>>> > >> > > On 13 March 2017 at 20:19, Tom Barber < > > > > tom.barber@meteorite.bi > > > > >>>> > > > > > >>>> > >> wrote: > > > > >>>> > >> > > > > > > >>>> > >> > >> Hi Imesha > > > > >>>> > >> > >> > > > > >>>> > >> > >> The best way to demonstrate this is to show you a > > > reference > > > > >>>> build > > > > >>>> > for > > > > >>>> > >> > >> OODT.. > > > > >>>> > >> > >> > > > > >>>> > >> > >> https://dl.dropboxusercontent. > > > > com/u/8503756/oodt-example.tgz > > > > >>>> > >> > >> > > > > >>>> > >> > >> If you can grab that archive and extract it, you'll > see > > > that > > > > >>>> is how > > > > >>>> > >> > >> currently OODT is deployed. > > > > >>>> > >> > >> > > > > >>>> > >> > >> If you take the file manager as the reference module > > > inside > > > > >>>> > >> oodt/filemgr > > > > >>>> > >> > >> you'll see > > > > >>>> > >> > >> > > > > >>>> > >> > >> etc/filemgr.properties > > > > >>>> > >> > >> > > > > >>>> > >> > >> and > > > > >>>> > >> > >> > > > > >>>> > >> > >> policy/oodt/* > > > > >>>> > >> > >> > > > > >>>> > >> > >> These are the configuration locations of a single file > > > > >>>> manager. > > > > >>>> > >> > >> > > > > >>>> > >> > >> The problem I want to solve is this: > > > > >>>> > >> > >> > > > > >>>> > >> > >> a) If I run > 1 file manager they are completely > > separate > > > > and > > > > >>>> they > > > > >>>> > >> don't > > > > >>>> > >> > >> know of each other. So using Zookeeper will allow > > multiple > > > > >>>> file > > > > >>>> > >> managers > > > > >>>> > >> > >> to > > > > >>>> > >> > >> register against ZK and learn of each other. > > > > >>>> > >> > >> > > > > >>>> > >> > >> b) Backing them onto ZK will allow file managers to > come > > > and > > > > >>>> go on > > > > >>>> > >> the > > > > >>>> > >> > >> fly, > > > > >>>> > >> > >> providing scaling capabilities or maybe fm's that are > > > > >>>> designed to > > > > >>>> > be > > > > >>>> > >> > >> transient. > > > > >>>> > >> > >> > > > > >>>> > >> > >> Just for clarity, the ZK configuration will be an > > optional > > > > >>>> > >> requirement, > > > > >>>> > >> > so > > > > >>>> > >> > >> we need to extend the existing configuration > mechanism, > > to > > > > >>>> support > > > > >>>> > >> both > > > > >>>> > >> > >> the > > > > >>>> > >> > >> current config and the ZK config instead of ZK being > > > > >>>> mandatory. > > > > >>>> > >> > >> > > > > >>>> > >> > >> Tom > > > > >>>> > >> > >> > > > > >>>> > >> > >> On Mon, Mar 13, 2017 at 3:20 AM, Imesha Sudasingha < > > > > >>>> > >> > >> imesha.13@cse.mrt.ac.lk> > > > > >>>> > >> > >> wrote: > > > > >>>> > >> > >> > > > > >>>> > >> > >> > Hi Tom, > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > Related to the conversation on JIRA [1] ; > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > I went through the CAS-File manager module and I now > > > > >>>> understand > > > > >>>> > >> how to > > > > >>>> > >> > >> > address ".properties" files. Since you mentioned in > > JIRA > > > > >>>> [2] that > > > > >>>> > >> > there > > > > >>>> > >> > >> are > > > > >>>> > >> > >> > occasions where we use *spring configuration files > > *for > > > > >>>> > >> configuration > > > > >>>> > >> > >> > purposes, I want to have a look at that type of > > > > >>>> configuration > > > > >>>> > too. > > > > >>>> > >> Can > > > > >>>> > >> > >> you > > > > >>>> > >> > >> > give me an example module where spring configuration > > > files > > > > >>>> are > > > > >>>> > >> used to > > > > >>>> > >> > >> load > > > > >>>> > >> > >> > configuration? > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > Also, will the content of a configuration file > exceed > > > 1MB > > > > >>>> > (Maximum > > > > >>>> > >> > data > > > > >>>> > >> > >> > size allowed in an ZNode) in any case? > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > Thank you! > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > [1] > > > > >>>> > >> > >> > https://issues.apache.org/jira > > > > >>>> /browse/OODT-945?focusedCommen > > > > >>>> > >> > >> tId=15906204& > > > > >>>> > >> > >> > page=com.atlassian.jira. > plugin.system.issuetabpanels: > > > > >>>> > >> > >> > comment-tabpanel#comment-15906204 > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > [2] > > > > >>>> > >> > >> > https://issues.apache.org/jira > > > > >>>> /browse/OODT-945?focusedCommen > > > > >>>> > >> > >> tId=15906524& > > > > >>>> > >> > >> > page=com.atlassian.jira. > plugin.system.issuetabpanels: > > > > >>>> > >> > >> > comment-tabpanel#comment-15906524 > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > Kind Regards, > > > > >>>> > >> > >> > *Imesha Sudasingha* > > > > >>>> > >> > >> > Undergraduate of Department of Computer Science and > > > > >>>> Engineering, > > > > >>>> > >> > >> > University of Moratuwa, > > > > >>>> > >> > >> > Sri Lanka. > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > < > > > > >>>> > >> > >> https://github.com/IMS94> > > > > >>>> > >> > >> > > > sudasingha > > > > > > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > > > > > >>>> > >> > >> > > > > >>>> > >> > > > > > > >>>> > >> > > > > > > >>>> > >> > > > > > >>>> > >> > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > > > --001a1143d3962686d4054bc1e65f--