ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Slim binary release and docker image for Apache Ignite
Date Wed, 17 Jun 2020 14:00:07 GMT
Hello!

I have just merged slim binary release to master.

I will now try to tweak nightly builds TC suite to build this package also.
It may be broken for some brief period of time.

Regards,
-- 
Ilya Kasnacheev


вт, 10 мар. 2020 г. в 18:24, Ilya Kasnacheev <ilya.kasnacheev@gmail.com>:

> Hello!
>
> I understand that procedures are courtesy Apache Ignite, but I assume that
> you went through them and can now repeat them reproducibly.
>
> Thank you!
> --
> Ilya Kasnacheev
>
>
> вт, 10 мар. 2020 г. в 18:12, Maxim Muzafarov <mmuzaf@apache.org>:
>
>> Ilya,
>>
>> It is not "mine" generic release procedures they are "ours" :-)
>> I've created the issue [1] based on current discussion thread.
>>
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-12765
>>
>> On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev <ilya.kasnacheev@gmail.com>
>> wrote:
>> >
>> > Hello!
>> >
>> > It is currently included.
>> >
>> > Maxim, can you prepare a slim release package based on your generic
>> release
>> > procedures? We could take a look at it and then perhaps add it to
>> downloads
>> > page officially.
>> >
>> > What do you think?
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > пт, 6 мар. 2020 г. в 20:48, Maxim Muzafarov <mmuzaf@apache.org>:
>> >
>> > > Ilya,
>> > >
>> > > `ignite-compress` is necessary for `wal page snapshot compression` [1]
>> > > which in turn shows very good performance results. So, I suppose, it's
>> > > better to include it to the "slim" binary.
>> > >
>> > > [1] https://issues.apache.org/jira/browse/IGNITE-11336
>> > >
>> > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev <
>> ilya.kasnacheev@gmail.com>
>> > > wrote:
>> > > >
>> > > > Hello!
>> > > >
>> > > > I added these because they are infrastructural to Ignite, as
>> opposed to
>> > > > integrations. They are also both very slim.
>> > > >
>> > > > Regards,
>> > > > --
>> > > > Ilya Kasnacheev
>> > > >
>> > > >
>> > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
>> > > > stephen.darlington@gridgain.com>:
>> > > >
>> > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I
know
>> very
>> > > few
>> > > > > people who use either.
>> > > > >
>> > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev <
>> ilya.kasnacheev@gmail.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > Hello!
>> > > > > >
>> > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0
RC1*
>> > > > > >
>> > > > > > I have prepared assemblies for Apache Ignite slim packaging:
>> > > > > > https://github.com/apache/ignite/tree/ignite-slim
>> > > > > >
>> > > > > > It is based on ignite-2.8
>> > > > > >
>> > > > > > You can build it with mvn initialize -Prelease,lgpl
>> > > > > -Dignite.edition=apache-
>> > > > > > ignite-slim after a normal release build.
>> > > > > >
>> > > > > > Please consider the contents of resulting
>> > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip
>> > > > > > It will be a 65M download as opposed to main 455M
>> apache-ignite-2.8.0
>> > > > > > distribution.
>> > > > > >
>> > > > > > My suggestion is that we can publish it as a post-release
step
>> since
>> > > it
>> > > > > > does not affect the release in any way. If we do, we should
>> probably
>> > > > > > indicate size for every kind of artifact in our download
>> section, so
>> > > our
>> > > > > > users can choose based on that information.
>> > > > > >
>> > > > > > The following modules are included:
>> > > > > >
>> > > > > > libs:
>> > > > > > core/shmem/jcache
>> > > > > > ignite-indexing
>> > > > > > ignite-spring
>> > > > > >
>> > > > > > libs/optional:
>> > > > > > ignite-compress  ignite-kubernetes  ignite-log4j2
>> > > ignite-rest-http
>> > > > > > ignite-spring-data_2.2
>> > > > > > ignite-jta       ignite-log4j       ignite-opencensus
>> ignite-slf4j
>> > > > > > ignite-urideploy
>> > > > > >
>> > > > > > I have kept examples, but removed benchmarks. sqlline still
>> present,
>> > > of
>> > > > > > course.
>> > > > > >
>> > > > > > ignite-zookeeper has a lot of dependencies (8M) which we
do not
>> > > update
>> > > > > > often enough (such as guava, curator, jackson), and which
may
>> form an
>> > > > > > attack surface.
>> > > > > >
>> > > > > > Not a pressing problem for 'integrated' ignite-zookeeper
users,
>> since
>> > > > > they
>> > > > > > can re-import these dependencies with more recent versions
using
>> > > maven or
>> > > > > > gradle.
>> > > > > > But for our users who rely on binary package for all JARs,
>> outdated
>> > > > > > dependencies may pose a problem.
>> > > > > >
>> > > > > > Therefore my opinion is to exclude this dependency and not
put
>> our
>> > > faith
>> > > > > on
>> > > > > > zookeeper dependency version.
>> > > > > >
>> > > > > > The same can be put for ignite-compress, and indeed, I'm
not
>> sure if
>> > > we
>> > > > > > should keep it.
>> > > > > >
>> > > > > > We can have an ad-hoc vote here.
>> > > > > >
>> > > > > > I would like to hear arguments for both inclusion and exclusion
>> of
>> > > > > > ignite-zookeeper and ignite-compress into slim package (in
any
>> > > > > combination).
>> > > > > >
>> > > > > > I would also like to know if you want a formal vote on the
>> issue.
>> > > > > >
>> > > > > > Regards,
>> > > > > > --
>> > > > > > Ilya Kasnacheev
>> > > > > >
>> > > > > >
>> > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda <dmagda@apache.org>:
>> > > > > >
>> > > > > >> Alex, could you please list all the modules that will
be
>> excluded?
>> > > It
>> > > > > will
>> > > > > >> help to confirm we haven't dumped anything essential.
>> > > > > >>
>> > > > > >> -
>> > > > > >> Denis
>> > > > > >>
>> > > > > >>
>> > > > > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
>> > > > > >> alexey.goncharuk@gmail.com> wrote:
>> > > > > >>
>> > > > > >>> Got it, sounds good!
>> > > > > >>> Should we consider the list of modules included
in the slim
>> package
>> > > > > >>> finalized?
>> > > > > >>>
>> > > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego
<isapego@apache.org
>> >:
>> > > > > >>>
>> > > > > >>>> Alexey, if I understand correctly, Ilya does
not suggest to
>> > > pre-built
>> > > > > >>>> binaries, just to ship it with configure script
>> pre-generated,
>> > > which
>> > > > > >>>> is a common practice for autotools packages.
Building will be
>> > > still
>> > > > > >>>> required for the user, but there will be less
requirements
>> and
>> > > > > >>>> possible errors during build.
>> > > > > >>>>
>> > > > > >>>> I like the idea. Let's do this.
>> > > > > >>>>
>> > > > > >>>> Best Regards,
>> > > > > >>>> Igor
>> > > > > >>>>
>> > > > > >>>>
>> > > > > >>>> On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk
<
>> > > > > >>>> alexey.goncharuk@gmail.com> wrote:
>> > > > > >>>>
>> > > > > >>>>> To me it doesn't really matter if it will
be 'slim' or
>> 'lite' :)
>> > > I
>> > > > > >>> would
>> > > > > >>>>> not name it 'core' because indeed it would
be confusing
>> with the
>> > > core
>> > > > > >>>>> module name.
>> > > > > >>>>>
>> > > > > >>>>> Agree that platforms support is useful,
so I would keep
>> them as
>> > > Ilya
>> > > > > >>>>> suggested. As for the C++ packages pre-build
- let's hear
>> out
>> > > Igor's
>> > > > > >>>>> opinion on this. Pre-built binaries certainly
add
>> usability, but
>> > > I am
>> > > > > >>> not
>> > > > > >>>>> sure how those binaries should be tested
afterwards.
>> > > > > >>>>>
>> > > > > >>>>> ср, 15 янв. 2020 г. в 18:33, Alexey
Kuznetsov <
>> > > akuznetsov@apache.org
>> > > > > >>> :
>> > > > > >>>>>
>> > > > > >>>>>> I'm +1 for "SLIM" it is a common name
in Docker world.
>> > > > > >>>>>>
>> > > > > >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr
Ivanov <
>> > > mr.weider@gmail.com>
>> > > > > >>>> wrote:
>> > > > > >>>>>>
>> > > > > >>>>>>> +1 for slim binary
>> > > > > >>>>>>> Plus docker-slim
>> > > > > >>>>>>> Plus RPM / DEB packages modularisation
like PHP
>> distribution —
>> > > > > >> with
>> > > > > >>>>> core
>> > > > > >>>>>>> and lots of integrations / modules.
>> > > > > >>>>>>>
>> > > > > >>>>>>>> On 15 Jan 2020, at 17:40, Ilya
Kasnacheev <
>> > > > > >>>> ilya.kasnacheev@gmail.com
>> > > > > >>>>>>
>> > > > > >>>>>>> wrote:
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> Hello!
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> I think we should name it "core"
since we already have
>> > > > > >>> ignite-core
>> > > > > >>>>> and
>> > > > > >>>>>> it
>> > > > > >>>>>>>> will be confusing. Maybe we
should go full 00s and call
>> it
>> > > > > >>> "lite"?
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> I also think we should keep
both .Net and C++. .Net is
>> > > runnable
>> > > > > >>> out
>> > > > > >>>>> of
>> > > > > >>>>>>> box
>> > > > > >>>>>>>> which is awesome, and C++ needs
building but it is rather
>> > > small
>> > > > > >>> in
>> > > > > >>>>>> source
>> > > > > >>>>>>>> form.
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> I also suggest a different change
to build process.
>> Let's ship
>> > > > > >>> C++
>> > > > > >>>>> with
>> > > > > >>>>>>>> automake, etc, already run,
for all binary packaging
>> options?
>> > > > > >>>> WDYT? I
>> > > > > >>>>>> can
>> > > > > >>>>>>>> assist in build process tuning.
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> Regards,
>> > > > > >>>>>>>> --
>> > > > > >>>>>>>> Ilya Kasnacheev
>> > > > > >>>>>>>>
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> ср, 15 янв. 2020 г. в
17:18, Denis Magda <
>> dmagda@apache.org>:
>> > > > > >>>>>>>>
>> > > > > >>>>>>>>> Alex,
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>> I'm on your end and support
the proposal. Could you also
>> > > > > >> clarify
>> > > > > >>>> if
>> > > > > >>>>>> you
>> > > > > >>>>>>>>> suggest we keeping or removing
C++ and .NET thick
>> clients?
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>> Speaking of the naming,
how about titling such packages
>> as
>> > > > > >>> 'core'
>> > > > > >>>>>>> instead
>> > > > > >>>>>>>>> of 'slim', i.e., 'apache-ignite-core-{version}'?
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>> -
>> > > > > >>>>>>>>> Denis
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>> On Wed, Jan 15, 2020 at
5:17 AM Ilya Kasnacheev <
>> > > > > >>>>>>> ilya.kasnacheev@gmail.com
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>> wrote:
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>>> Hello!
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>> Pavel, I believe these
JARs are fully covered by the
>> list of
>> > > > > >>>>> modules
>> > > > > >>>>>>>>>> specified above.
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>> Regards,
>> > > > > >>>>>>>>>> --
>> > > > > >>>>>>>>>> Ilya Kasnacheev
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>> ср, 15 янв. 2020
г. в 14:50, Pavel Tupitsyn <
>> > > > > >>>> ptupitsyn@apache.org
>> > > > > >>>>>> :
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>>> I like the idea,
current distribution is certainly
>> too big.
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>> Here is a list of
jar files we include in NuGet
>> package:
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>> cache-api-1.0.0.jar
>> > > > > >>>>>>>>>>> commons-codec-1.11.jar
>> > > > > >>>>>>>>>>> commons-logging-1.1.1.jar
>> > > > > >>>>>>>>>>> h2-1.4.197.jar
>> > > > > >>>>>>>>>>> ignite-core-2.9.0-SNAPSHOT.jar
>> > > > > >>>>>>>>>>> ignite-indexing-2.9.0-SNAPSHOT.jar
>> > > > > >>>>>>>>>>> ignite-shmem-1.0.0.jar
>> > > > > >>>>>>>>>>> ignite-spring-2.9.0-SNAPSHOT.jar
>> > > > > >>>>>>>>>>> lucene-analyzers-common-7.4.0.jar
>> > > > > >>>>>>>>>>> lucene-core-7.4.0.jar
>> > > > > >>>>>>>>>>> lucene-queryparser-7.4.0.jar
>> > > > > >>>>>>>>>>> spring-aop-4.3.18.RELEASE.jar
>> > > > > >>>>>>>>>>> spring-beans-4.3.18.RELEASE.jar
>> > > > > >>>>>>>>>>> spring-context-4.3.18.RELEASE.jar
>> > > > > >>>>>>>>>>> spring-core-4.3.18.RELEASE.jar
>> > > > > >>>>>>>>>>> spring-expression-4.3.18.RELEASE.jar
>> > > > > >>>>>>>>>>> spring-jdbc-4.3.18.RELEASE.jar
>> > > > > >>>>>>>>>>> spring-tx-4.3.18.RELEASE.jar
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>> Those are required
for SQL and Spring configs to work
>> > > > > >>> properly,
>> > > > > >>>>>>>>>>> maybe we want to
include them into the slim distro as
>> well.
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>> On Wed, Jan 15,
2020 at 2:25 PM Ilya Kasnacheev <
>> > > > > >>>>>>>>>> ilya.kasnacheev@gmail.com
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>> wrote:
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>>> Hello!
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> This is a reasonable
idea.
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> I think we should
also drop benchmarks/ directory
>> from
>> > > that
>> > > > > >>>>> build,
>> > > > > >>>>>>>>> it's
>> > > > > >>>>>>>>>>> 60M
>> > > > > >>>>>>>>>>>> of (potentially
vulnerable) JARs that are not needed
>> by an
>> > > > > >>>>> average
>> > > > > >>>>>>>>>>>> developer's
use cases.
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> Regards,
>> > > > > >>>>>>>>>>>> --
>> > > > > >>>>>>>>>>>> Ilya Kasnacheev
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> ср, 15 янв.
2020 г. в 13:10, Alexey Goncharuk <
>> > > > > >>>>>>>>>>> alexey.goncharuk@gmail.com
>> > > > > >>>>>>>>>>>>> :
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> Igniters,
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> I would
like to discuss with the community a
>> possibility
>> > > > > >> to
>> > > > > >>>>> create
>> > > > > >>>>>>>>>>>>> additional
'slim' binary releases and docker images
>> for
>> > > > > >>> Apache
>> > > > > >>>>>>>>>> Ignite.
>> > > > > >>>>>>>>>>>> The
>> > > > > >>>>>>>>>>>>> reason is
two-fold:
>> > > > > >>>>>>>>>>>>> * The full
set of 3rd party libraries distributed
>> with
>> > > > > >>> Apache
>> > > > > >>>>>>>>> Ignite
>> > > > > >>>>>>>>>>>> looks
>> > > > > >>>>>>>>>>>>> too large
for me. I know there is an ongoing
>> activity
>> > > > > >>> towards
>> > > > > >>>>> more
>> > > > > >>>>>>>>>>> clear
>> > > > > >>>>>>>>>>>>> Ignite modularization
[1][2][3], but this seems to
>> be
>> > > > > >> quite
>> > > > > >>> a
>> > > > > >>>>> long
>> > > > > >>>>>>>>>>>> process.
>> > > > > >>>>>>>>>>>>> On the other
hand, creating a slim release may give
>> an
>> > > > > >>>> immediate
>> > > > > >>>>>>>>>>> benefit
>> > > > > >>>>>>>>>>>> to
>> > > > > >>>>>>>>>>>>> the users
who are interested in a smaller image. For
>> > > > > >>> example,
>> > > > > >>>>>>>>>> removing
>> > > > > >>>>>>>>>>>> the
>> > > > > >>>>>>>>>>>>> benchmarks
alone from the binary release saves 80M.
>> > > > > >>>>>>>>>>>>> * As Ilya
Kasnacheev demonstrated [4], the more 3rd
>> party
>> > > > > >>>>>>>>> libraries
>> > > > > >>>>>>>>>> we
>> > > > > >>>>>>>>>>>>> have, the
more potential vulnerabilities will show
>> up in
>> > > > > >>> audit
>> > > > > >>>>>>>>> tools.
>> > > > > >>>>>>>>>>>> This
>> > > > > >>>>>>>>>>>>> may be a
formal barrier for Apache Ignite adoption
>> and
>> > > > > >>> moving
>> > > > > >>>> to
>> > > > > >>>>>>>>>>>> production
>> > > > > >>>>>>>>>>>>> for many
users. Having a slim image with the minimum
>> > > > > >> number
>> > > > > >>> of
>> > > > > >>>>>>>>>>>> dependencies
>> > > > > >>>>>>>>>>>>> (yet complete
enough to fit the majority of
>> use-cases)
>> > > > > >>>>>>>>> significantly
>> > > > > >>>>>>>>>>>>> reduces
this risk.
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> I wonder
what community thinks regarding this idea?
>> Given
>> > > > > >>> the
>> > > > > >>>>>>>>> recent
>> > > > > >>>>>>>>>>>> study
>> > > > > >>>>>>>>>>>>> of Apache
Ignite use-cases, I suggest the following
>> list
>> > > > > >> of
>> > > > > >>>>>> modules
>> > > > > >>>>>>>>>> to
>> > > > > >>>>>>>>>>> be
>> > > > > >>>>>>>>>>>>> included
to the slim release/image (a subject to
>> discuss,
>> > > > > >> of
>> > > > > >>>>>>>>> course):
>> > > > > >>>>>>>>>>>>> * ignite-core
>> > > > > >>>>>>>>>>>>> * ignite-indexing
>> > > > > >>>>>>>>>>>>> * ignite-rest-http
>> > > > > >>>>>>>>>>>>> * ignite-spring
>> > > > > >>>>>>>>>>>>> * ignite-log4j
>> > > > > >>>>>>>>>>>>> * ignite-log4j2
>> > > > > >>>>>>>>>>>>> * ignite-slf4j
>> > > > > >>>>>>>>>>>>> * ignite-urideploy
>> > > > > >>>>>>>>>>>>> * ignite-kubernetes
>> > > > > >>>>>>>>>>>>> * ignite-opencensus
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> [1]
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > >
>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
>> > > > > >>>>>>>>>>>>> [2]
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > >
>> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
>> > > > > >>>>>>>>>>>>> [3]
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > >
>> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
>> > > > > >>>>>>>>>>>>> [4]
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > >
>> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> --AG
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>>
>> > > > > >>>>>> --
>> > > > > >>>>>> Alexey Kuznetsov
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > > > >
>> > > > >
>> > >
>>
>

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