Return-Path: Delivered-To: apmail-incubator-chukwa-dev-archive@www.apache.org Received: (qmail 44316 invoked from network); 20 Sep 2010 22:58:56 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Sep 2010 22:58:56 -0000 Received: (qmail 11034 invoked by uid 500); 20 Sep 2010 22:58:56 -0000 Delivered-To: apmail-incubator-chukwa-dev-archive@incubator.apache.org Received: (qmail 10996 invoked by uid 500); 20 Sep 2010 22:58:56 -0000 Mailing-List: contact chukwa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: chukwa-dev@incubator.apache.org Delivered-To: mailing list chukwa-dev@incubator.apache.org Received: (qmail 10988 invoked by uid 99); 20 Sep 2010 22:58:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Sep 2010 22:58:56 +0000 X-ASF-Spam-Status: No, hits=3.3 required=10.0 tests=HTML_MESSAGE,NO_RDNS_DOTCOM_HELO,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [69.147.107.20] (HELO mrout1-b.corp.re1.yahoo.com) (69.147.107.20) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Sep 2010 22:58:49 +0000 Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o8KMvvN8080732; Mon, 20 Sep 2010 15:57:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage:content-type:mime-version; b=fvw6F39t9Gpcvn4wIPOtupUJ/ufw8imcaZwRk7hbXgMpzfmmxjnil4UVXY+PPtgt Received: from SP2-EX07VS05.ds.corp.yahoo.com ([98.137.59.23]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Mon, 20 Sep 2010 17:57:57 -0500 From: Eric Yang To: "chukwa-dev@incubator.apache.org" , "billgraham@gmail.com" Date: Mon, 20 Sep 2010 17:57:55 -0500 Subject: Re: Cluster-specific Adaptors Thread-Topic: Cluster-specific Adaptors Thread-Index: ActZDxs35Gk93JDrR6y9EkiQHewzpgACCeVn Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8BD3503C0D7eyangyahooinccom_" MIME-Version: 1.0 --_000_C8BD3503C0D7eyangyahooinccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bill, This might be hacky but it should be possible to have adaptor specific para= ms to include tags. Ari, what do you think? Regards, Eric On 9/20/10 2:58 PM, "Bill Graham" wrote: Hi, In CHUKWA-515 we discussed the possibility being able to add an adaptor bound to a given cluster: https://issues.apache.org/jira/browse/CHUKWA-515?focusedCommentId=3D1290581= 1&page=3Dcom.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#a= ction_12905811 I can actually see this being useful, especially now that it's easier to add/remove agents with the Adaptor REST API. Looking into the code it doesn't seem like it would be that hard to do, but I want to make sure I'm not overlooking anything. It seems like we could support this with a few small changes: - Add the concept of tags to the Adaptor interface. - AbstractAdator would support a getTags method which would return the union of tags set on the Adaptor and the default tags on the DataFactory. - Internal tag implementations on each would change to store tags in maps, instead of concat'ed strings. This would allow for a "last in wins" type of functionality so tags could be overriden. This assumes of course that there should never be more than one of the same tag key value, which I _assume_ is the case. - The ChunkImpl constructor will call getTags on the agent, instead of getDefaultTags the data factory. The trickiest part as I see it is figuring out how to change the add adaptor string syntax in ChukwaAgetn.processAddCommandE in a way that both makes sense and doesn't break things. In it's current form it doesn't have room for easy expansion except at the end of the line: add [name =3D] Any thoughts or suggestions? There's also a potential gotcha with all the impls of Adaptor.parseArgs either breaking or needing to change.... thanks, Bill --_000_C8BD3503C0D7eyangyahooinccom_--