From dev-return-46865-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Mon Aug 5 15:36:11 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 85842180181 for ; Mon, 5 Aug 2019 17:36:11 +0200 (CEST) Received: (qmail 12737 invoked by uid 500); 5 Aug 2019 15:36:10 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 12718 invoked by uid 99); 5 Aug 2019 15:36:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Aug 2019 15:36:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id F05B91A1864 for ; Mon, 5 Aug 2019 15:36:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 1P6zBAuFL_A9 for ; Mon, 5 Aug 2019 15:36:06 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::243; helo=mail-lj1-x243.google.com; envelope-from=nizhikov.dev@gmail.com; receiver= Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 9F6907D3FC for ; Mon, 5 Aug 2019 15:36:05 +0000 (UTC) Received: by mail-lj1-x243.google.com with SMTP id y17so55112621ljk.10 for ; Mon, 05 Aug 2019 08:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:subject:to:date:in-reply-to:references :mime-version; bh=vFh9g4H6ksYQ/CVn24oMdqxW08bgGLUopDzAt3+zveM=; b=W6q73+PrmKZwtbH530fHMiaevkOyZtDVtPdLbxb0hmKQLKwF+H82TAlmCfqNkzNxDt zdIbKFMSHDjojTa9tAsTQPsqTEH3suCWKc7gaSphkqw//lz1LEIU58kgPtFP2bXkp+k+ 7XlwRQOUXLxpsYup86j87FrfI6k+9i5F3z+a7hPL1Ebv7XEt6rAJkSj6w/dCa+goL2mr f1ZOGyefyhZiDX/LOnCuVTMZ1nAm1dDvnvBhcVedM09/ceef3B/oVZ7j0+PmR2w6LpyV cnRhbO+YJdL/jriVZ3kDCNbs5Thjh9rFTyw7/S51qMML+BogsJOycpJcqb40suai/N98 Dgww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:subject:to:date :in-reply-to:references:mime-version; bh=vFh9g4H6ksYQ/CVn24oMdqxW08bgGLUopDzAt3+zveM=; b=S9Tt2DDyriEST9YakQ4xusGIE4WtxZ7J9icPaSLK8yMmWjC3On9B0EskmqLcsWAfW6 N9BHc7D18ugm1sKkUWP6rayVolKxUQiN8z6+qJufFsYu7jO5JbPGZWciPERoWF6Da13I bTMKjgcXK1/DhPnBEs5wnGgEPfH3ng8g331b6EiJhU7JrwDujt/oLf7sMJ4I9XoOgBzE LEPVxiQl406Y0ksb12jgdNSBqLP68cW+2Irvo1JBqVifQyAafr21lCwxL4zbBegp7WLN /jRaRg8HWHx2GdaOttPmfB1RX6CE8Iou1Ts4eIOKOOXaBL5nS0qUFIGzq3rAjzH2uJqa nZ1g== X-Gm-Message-State: APjAAAXv+j2qJBznowJliE6pQphu6KScKDRRN8M+dLzpH4K3YiJBMezv /uygUsB94YmyCnXBxHHe+NTnN1Q0 X-Google-Smtp-Source: APXvYqx2HTK2RUZ/pUVYZrAAk6mqfA7onYJ952EdlMAzYkj3RxqxsxO3D7Czy42C9eFWZP5d8v9I5Q== X-Received: by 2002:a2e:b0e6:: with SMTP id h6mr25976048ljl.18.1565019358600; Mon, 05 Aug 2019 08:35:58 -0700 (PDT) Received: from newDragon ([194.186.207.140]) by smtp.googlemail.com with ESMTPSA id e26sm15036204lfc.68.2019.08.05.08.35.57 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Aug 2019 08:35:57 -0700 (PDT) Sender: =?UTF-8?B?0J3QuNC60L7Qu9Cw0Lkg0JjQttC40LrQvtCy?= From: Nikolay Izhikov X-Google-Original-From: Nikolay Izhikov Message-ID: <88bff1f289f492c533d852d3d204c458ee3ad527.camel@gmail.com> Subject: Re: [DISCUSSION][IEP-35] Metrics configuration To: dev@ignite.apache.org Date: Mon, 05 Aug 2019 18:38:51 +0300 In-Reply-To: References: <4f4d71bacdd0356d83a8775eea8897c21ce1ea35.camel@gmail.com> <975b6036c74338585df228af92c88dfd325cbdac.camel@gmail.com> <043AEF07-1F5B-4750-842E-3637EEA12769@gmail.com> <425d1c147342ce21952eab6b6531f2160de1b921.camel@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-GwBFWYPEu7p1M6sUNg45" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 --=-GwBFWYPEu7p1M6sUNg45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Andrey. > Not necessary if we have exponential bounds' values for histograms. What do you mean by "exponential bounds"? > Anyway, in current solution it looks ugly and not usable. Thanks, for the feedback, appreciate you ownesty. > No. But we should admit that this is bad decision and do not include this= change to the code base. What is your proposal? How metrics configuration should work? > Yes. But it still will not give enough accuracy. Enough for what? =D0=92 =D0=9F=D0=BD, 05/08/2019 =D0=B2 18:29 +0300, Andrey Gura =D0=BF=D0= =B8=D1=88=D0=B5=D1=82: > > > - metric configuration is node local (not cluster wide). > > This issue is easy to solve on the user-side and in Ignite core. >=20 > It's imaginary simplicity. The first, you need some additional > automation on user-side in order to configure all nodes of the > cluster. The second, new nodes can join to the cluster and > configuration will be different on new node and on other nodes of the > cluster. This leads to complication whole functionality. Anyway, I > don't like such simplified solution because at the moment it brings > more problems than value. >=20 > > The easiest solution was implemented. > > Do we want to make it more complex right now :)? >=20 > No. But we should admit that this is bad decision and do not include > this change to the code base. >=20 > > The reason it exists in PR - we already have this parameter in DataStor= ageConfiguration#getMetricsSubIntervalCount >=20 > I believe this method should be deprecated and removed in major release. >=20 > > I think the user should be able to configure buckets for histogram and = rateTimeInterval for hitrate. >=20 > Not necessary if we have exponential bounds' values for histograms. > Anyway, in current solution it looks ugly and not usable. >=20 > > Ignite has dozens of use-cases and deployment modes, seems, > > we can't cover it all with the single predefined buckets/rateTimeInterv= al set. >=20 > Yes. But it still will not give enough accuracy. >=20 > On Mon, Aug 5, 2019 at 5:25 PM Nikolay Izhikov wrot= e: > >=20 > > Hello, Andrey. > >=20 > > > - metric configuration is node local (not cluster wide). > >=20 > > This issue is easy to solve on the user-side and in Ignite core. > >=20 > > > - metric configuration doesn't survive node restart. > >=20 > > We decide to go with the simplest solution, for now. > > The easiest solution was implemented. > > Do we want to make it more complex right now :)? > >=20 > > > - User shouldn't configure hit rate metrics at runtime in most cases. > >=20 > > I agree with you - the size of the counters array looks odd as a config= uration parameter. > > The reason it exists in PR - we already have this parameter in DataStor= ageConfiguration#getMetricsSubIntervalCount > >=20 > > > - May be it is enough for user to have histograms with pre-configured= buckets > > > So I think we should drop this change and idea about runtime histrogr= am and hit rate configuration. > >=20 > > I think the user should be able to configure buckets for histogram and = rateTimeInterval for hitrate. > >=20 > > Ignite has dozens of use-cases and deployment modes, seems, > > we can't cover it all with the single predefined buckets/rateTimeInterv= al set. > >=20 > > =D0=92 =D0=9F=D0=BD, 05/08/2019 =D0=B2 16:59 +0300, Andrey Gura =D0=BF= =D0=B8=D1=88=D0=B5=D1=82: > > > Igniters, > > >=20 > > > I've took a look to the PR and I want follow up this discussion again= . > > >=20 > > > Proposed solution has a couple of significant drawbacks: > > >=20 > > > - metric configuration is node local (not cluster wide). > > > - metric configuration doesn't survive node restart. > > >=20 > > > This drawbacks make configuration complex, annoying and useless in mo= st cases. > > >=20 > > > Moreover, I think that: > > >=20 > > > - User shouldn't configure hit rate metrics at runtime in most cases. > > > Especially HitRateMetric.size because it's just details of > > > implementation. Purpose of size is plots smoothing and this parameter > > > could be fixed (e.g. 16 is enough). HitRate metric is just LongMetric > > > but with additional feature. > > > - May be it is enough for user to have histograms with pre-configured > > > buckets. The trick here is properly chosen bounds. It seems that > > > exponentially chosen values will fit for most cases. So we can avoid > > > runtime configuration for histograms. > > > - We can also provide percentile metric for more accurate > > > measurements. Yes, it will bring additional performance impact and > > > accuracy will not be the best. But it will more clearly and will not > > > require configuration. > > >=20 > > > So I think we should drop this change and idea about runtime > > > histrogram and hit rate configuration. > > >=20 > > > Thoughts? > > >=20 > > > On Tue, Jul 9, 2019 at 2:06 PM Nikolay Izhikov = wrote: > > > >=20 > > > > Igniters, > > > >=20 > > > > I made a PR for metrics configuration. > > > >=20 > > > > Please, review > > > >=20 > > > > https://github.com/apache/ignite/pull/6676/files > > > >=20 > > > > =D0=92 =D0=92=D1=82, 09/07/2019 =D0=B2 12:27 +0300, Nikolay Izhikov= =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > Hello, Alex. > > > > >=20 > > > > > OK, Let's go with the simplest solution. > > > > > I will provide API and JMX method for metrics configuration short= ly. > > > > >=20 > > > > > =D0=92 =D0=9F=D0=BD, 08/07/2019 =D0=B2 18:23 +0300, Alexey Goncha= ruk =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > Nikolay, > > > > > >=20 > > > > > > To me a separate metrics configuration file seems to be not ver= y > > > > > > user-friendly. First of all, it does not allow to configure the= system only > > > > > > from Java code. Second, having multiple configuration files see= m to be > > > > > > quite confusing for end users (judging by the logging configura= tion > > > > > > questions). > > > > > >=20 > > > > > > Perhaps, we will still end up with the configuration file - but= for now I > > > > > > would put this aside for a more thorough brainstorm and added t= he JMX and > > > > > > internal API for changing metrics configuration. > > > > > >=20 > > > > > > =D0=BF=D1=82, 5 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 14:17, = Seliverstov Igor : > > > > > >=20 > > > > > > > Igniters, > > > > > > >=20 > > > > > > > One more question on topic. > > > > > > >=20 > > > > > > > Should we preserve metrics configuration on restart? (I think= we should) > > > > > > >=20 > > > > > > > If so, which configuration use after restart? Defined in conf= ig file or > > > > > > > saved in config storage? (I guess, saved configuration should= have a > > > > > > > priority) > > > > > > >=20 > > > > > > > So, how to tell users that any changes in configuration file = have no > > > > > > > effect on Ignite configuration after first start? > > > > > > >=20 > > > > > > > I think there are too many open questions and (at least at no= w) we should > > > > > > > provide only JMX API until all of the questions are clarified= . > > > > > > >=20 > > > > > > > Regards, > > > > > > > Igor > > > > > > >=20 > > > > > > > > 4 =D0=B8=D1=8E=D0=BB=D1=8F 2019 =D0=B3., =D0=B2 19:55, Niko= lay Izhikov > > > > > > >=20 > > > > > > > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): > > > > > > > >=20 > > > > > > > > Hello, Andrey. > > > > > > > >=20 > > > > > > > > > 3. I can't imagine that adequate values will be chosen on= project > > > > > > > > > setup stage. > > > > > > > >=20 > > > > > > > > Configuration file required in the case we adds new node or= replace > > > > > > >=20 > > > > > > > existing to the cluster. > > > > > > > > Use can have parameters similar to Ignite configuration, lo= g > > > > > > >=20 > > > > > > > configuration files. > > > > > > > >=20 > > > > > > > > > My proposal is adding API for boundaries configuration to= the metrics > > > > > > > > > framework and expose it via JMX > > > > > > > >=20 > > > > > > > > Agree. I think we should have both: > > > > > > > >=20 > > > > > > > > 1. Configuration file. > > > > > > > > 2. JMX API to change bounaries of histogram *and HitRateMet= ric params*. > > > > > > > >=20 > > > > > > > > But, if you and other community member are against config f= ile, let's > > > > > > >=20 > > > > > > > have only JMX. > > > > > > > > Seems, JMX will provide required level of configurability f= or metrics. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > =D0=92 =D0=A7=D1=82, 04/07/2019 =D0=B2 17:53 +0300, Andrey = Gura =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > > > > Igniters, > > > > > > > > >=20 > > > > > > > > > I rethought the issue and I see some problems: > > > > > > > > >=20 > > > > > > > > > 1. It seems that in most cases bucket boundaries configur= ation will be > > > > > > > > > problem for user. Absolute values for latency boundaries = it is very > > > > > > > > > odd choice. > > > > > > > > > 2. Also seems that latency for most caches (if we configu= re cache > > > > > > > > > metrics fro example) will be similar. > > > > > > > > > 3. I can't imagine that adequate values will be chosen on= project > > > > > > > > > setup stage. So chosen values should be changed in the fu= ture. > > > > > > > > >=20 > > > > > > > > > Solution with configuration file looks unnatural and crea= tes more > > > > > > > > > problems than could solve. > > > > > > > > >=20 > > > > > > > > > My proposal is adding API for boundaries configuration to= the metrics > > > > > > > > > framework and expose it via JMX (at this step). It still = provides > > > > > > > > > configuration possibility but don't force user to do it. > > > > > > > > >=20 > > > > > > > > > Also we should chose default values for bucket boundaries= . And it is > > > > > > > > > most complex problem at the moment :) Let's discuss it. > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > On Wed, Jul 3, 2019 at 4:49 PM Andrey Gura wrote: > > > > > > > > > >=20 > > > > > > > > > > Nikolai, > > > > > > > > > >=20 > > > > > > > > > > Metric is disabled if it doesn't allocate any memory an= d doesn't > > > > > > > > > > update any variable because doesn't have any value. Ide= ally disabling > > > > > > > > > > metrics for some cache should be equal to cache stoppin= g. > > > > > > > > > >=20 > > > > > > > > > > On Fri, Jun 28, 2019 at 1:02 PM Nikolay Izhikov > > > > > > >=20 > > > > > > > wrote: > > > > > > > > > > >=20 > > > > > > > > > > > Hello, Alexey. > > > > > > > > > > >=20 > > > > > > > > > > > Thanks for the feedback! > > > > > > > > > > >=20 > > > > > > > > > > > > My only concert is that we should have the metrics = framework > > > > > > >=20 > > > > > > > configuration > > > > > > > > > > > > as the first-citizen of the framework itself > > > > > > > > > > >=20 > > > > > > > > > > > Yes. I planned to add `void configure(String param)` = method to the > > > > > > >=20 > > > > > > > metric API. > > > > > > > > > > >=20 > > > > > > > > > > > > but change the metrics parameters in > > > > > > > > > > > > runtime from JMX or command-line, etc. > > > > > > > > > > >=20 > > > > > > > > > > > I've add requirement of JMX method to the ticket: > > > > > > > > > > >=20 > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-11927 > > > > > > > > > > >=20 > > > > > > > > > > > > Another concern is to have an > > > > > > > > > > > > ability to disable/enable metrics per metrics group= /prefix. > > > > > > > > > > >=20 > > > > > > > > > > > Yes, we discusss it. > > > > > > > > > > > But, let's make it clear: > > > > > > > > > > >=20 > > > > > > > > > > > *What is disabling metric?* > > > > > > > > > > >=20 > > > > > > > > > > > Looks like exporter filter solve this task. > > > > > > > > > > >=20 > > > > > > > > > > > =D0=92 =D0=A7=D1=82, 27/06/2019 =D0=B2 16:24 +0300, A= lexey Goncharuk =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > > > > > > > Nikolay, > > > > > > > > > > > >=20 > > > > > > > > > > > > My only concert is that we should have the metrics = framework > > > > > > >=20 > > > > > > > configuration > > > > > > > > > > > > as the first-citizen of the framework itself. This = way, we can > > > > > > >=20 > > > > > > > configure > > > > > > > > > > > > the metrics not only from file, but change the metr= ics parameters in > > > > > > > > > > > > runtime from JMX or command-line, etc. Another conc= ern is to have an > > > > > > > > > > > > ability to disable/enable metrics per metrics group= /prefix. > > > > > > > > > > > >=20 > > > > > > > > > > > > The logger-like configuration meets these suggestio= ns given that the > > > > > > > > > > > > configuration is generalized into the metrics frame= work. > > > > > > > > > > > >=20 > > > > > > > > > > > > What do you think? > > > > > > > > > > > >=20 > > > > > > > > > > > > =D1=87=D1=82, 27 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. = =D0=B2 12:30, Nikolay Izhikov : > > > > > > > > > > > >=20 > > > > > > > > > > > > > Hello, Igniters. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > As you may know, I've contributed Phase1 [1] for = IEP-35 [2]. > > > > > > > > > > > > > Now we have metrics subsystem and can create and = export any metrics > > > > > > >=20 > > > > > > > from > > > > > > > > > > > > > Ignite. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > I think user(administrator of Ignite) should be a= ble to configure > > > > > > >=20 > > > > > > > some > > > > > > > > > > > > > metrics params in a common way [3] > > > > > > > > > > > > >=20 > > > > > > > > > > > > > I propose to use the same way from logging framew= orks. > > > > > > > > > > > > > We should define some file format Ignite can unde= rstand. > > > > > > > > > > > > > An administrator fills configuration file to conf= igure one or > > > > > > >=20 > > > > > > > several > > > > > > > > > > > > > metrics. > > > > > > > > > > > > > Ignite will analyze the file and use provided par= ams during metrics > > > > > > > > > > > > > creation. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > For now, we have 2 types of metrics that should b= e configured: > > > > > > > > > > > > >=20 > > > > > > > > > > > > > * HistrogramMetric [4] > > > > > > > > > > > > > This metric is a count of measurem= ent that falls into > > > > > > > > > > > > > predefined intervals. > > > > > > > > > > > > > An example is "Request processing = time distribution". > > > > > > > > > > > > > We want to calculate a count of re= quests processed > > > > > > >=20 > > > > > > > quicker > > > > > > > > > > > > > then 50ms, 50-100, 100-250, 250-500 and slower. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > * HitRateMetric [5] > > > > > > > > > > > > > This metric is a count of events i= n the last time > > > > > > >=20 > > > > > > > interval. > > > > > > > > > > > > > An example is the "Count of reques= ts processed in > > > > > > >=20 > > > > > > > the last > > > > > > > > > > > > > 5 seconds". > > > > > > > > > > > > >=20 > > > > > > > > > > > > > Example of file content: > > > > > > > > > > > > >=20 > > > > > > > > > > > > > ```` > > > > > > > > > > > > > cache.my-cahe.GetLatency=3D50,100,250,500 #Params= for the histogram > > > > > > >=20 > > > > > > > metric > > > > > > > > > > > > > with the name `cache.my-cahe.get` > > > > > > > > > > > > > cache.my-cache.RebalancingKeysRate=3D60000 #Param= for existing > > > > > > >=20 > > > > > > > HitRateMetric > > > > > > > > > > > > > that hold "Estimated rebalancing speed in keys". > > > > > > > > > > > > > ```` > > > > > > > > > > > > >=20 > > > > > > > > > > > > > Please, share your vision. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > [1] > > > > > > > > > > > > >=20 > > > > > > >=20 > > > > > > > https://github.com/apache/ignite/commit/fdaa310430aefff07994e= b35510d3416886b5bbe > > > > > > > > > > > > > [2] > > > > > > > > > > > > >=20 > > > > > > >=20 > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pag= eId=3D112820392 > > > > > > > > > > > > > [3] https://issues.apache.org/jira/browse/IGNITE-= 11927 > > > > > > > > > > > > > [4] > > > > > > > > > > > > >=20 > > > > > > >=20 > > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src= /main/java/org/apache/ignite/internal/processors/metric/impl/HistogramMetri= c.java > > > > > > > > > > > > > [5] > > > > > > > > > > > > >=20 > > > > > > >=20 > > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src= /main/java/org/apache/ignite/internal/processors/metric/impl/HitRateMetric.= java > > > > > > > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 --=-GwBFWYPEu7p1M6sUNg45 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEOiTcLcdgyP2exB5ZbiaPbjg91GUFAl1ITYsACgkQbiaPbjg9 1GX75Qf/dJYArNqI9906C2cWU4bvSpk9wDmdOhgeyCnvUY/hDtEP4i48OBEbzXE9 jeAFLL4Dcx1Gafkj7TmRStKxskengSI27lMkakQS8VuAGZayzqshECAUxP7++4NI Oi1g8l7g0t9FSdIjBZFudD2kJaQoCuGf1VRukU3U7mxuzzL2/ra3s5mzgnYdX4Ok Pm+rFRfvDnCY+vY754CKnTnKBUlFEvWJtHfwcg8vRfw2vo8nAZprvpX8YR6Tdymi ig+bEX6/S3A/fc4fVSbkg3USVWncaAchK28Q69hoHdy81gwOCgs7W11/EmxMvJ9m Jhz7NxY9WGIJXSl5ecBnWkDcV2xgYw== =3Q0Y -----END PGP SIGNATURE----- --=-GwBFWYPEu7p1M6sUNg45--