ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Joining an ignite cluster (via ignite.sh) delay
Date Mon, 20 Apr 2015 03:49:59 GMT
On 19.04.2015 17:11, Konstantin Boudnik wrote:
> On Sun, Apr 19, 2015 at 09:01AM, Branko ─îibej wrote:
>> On 19.04.2015 00:57, Dmitriy Setrakyan wrote:
>>> On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <ognen.duzlevski@gmail.com>
>>> wrote:
>>>> Hello,
>>>> I have noticed that with 1.0.0-incubating there is somewhat of a delay with
>>>> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
>>>> examples/configs/example-ignite.sh & and then move on the next instance.
>>>> The same command on the next instance takes about 5-10 seconds before it
>>>> returns and each additional instance seems to take even longer. Anyone else
>>>> notice this?
>>> You should not be getting such pauses. What OS are you running on?
>>>> I get this when I run ingnite.sh (1.0.0-incubating):
>>>> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
>>>> [15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
>>>> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
>>> You can download it here: http://www.gridgain.com/download/editions/
>> HUH?? Excuse me, is Ignite looking at GridGain's site for version
>> updates? How on earth can GridGain be offering versions of Ignite that
>> have not been released, and worse, how can you possibly call the package
> Brane, I believe we have agreed that if anyone wants to offer their own builds
> of Ignite - it is ok, until they are not confused with official Apache
> releases of Ignite? If so, then someone moving at the different pace than
> Ignite can put binaries for uploads and call it a dev snapshot or community
> edition or whatever, no? Just trying to make sure we're on the same page.

Certainly, I have no argument with that. However:

  * The build is promoted on the site as "GridGain Community Edition",
    which is perfectly fine, but the package is called "gridgain-ignite"
    and that's not fine;
  * It would be OK if were called 'apache-ignite-x.y.z.-bin-blabla' and
    promoted as "Ignite Binaries provided by GridGain" or similar, but
    in that case, one can't actually use a different version number than
    whatever has been published by the Ignite podling.

Also note that, according to the OP, the log message (see above) implies
that there's a new version of Ignite available ... which implies it's
looking at the GridGain site. That's OK for for a GridGain Community
Edition to do, but not OK for (convenience) binaries or builds source
published on ASF mirrors. I'm guessing there's some confusion here as to
which binaries were actually used: the goal of our branding and
trademarks policies are to avoid exactly this kind of confusion.

To summarize:

  * GridGain Enterprise Edition (e.g.,
    gridgain-enterprise-foo-version.zip) is fine;
  * GridGain Community Edition (e.g.,
    gridgain-community-foo-version.zip) is fine;
  * Apache Ignite binaries provided by GridGain (e.g.,
    apache-ignite-foo-version.zip) is fine, too, as long as the binaries
    don't go announcing version updates from info published on the
    GridGain site (but it's OK to look for info on the Ignite site); and
    as long as they either don't contain the LGPL&Co. dependencies, or
    very explicitly warn users that distribution rights are not covered
    by ALv2;
  * What's currently published is confusing, i.e., not OK.

I'd also recommend that whatever GridGain publishes as their open source
edition should have licensing terms and restrictions explained clearly
prominently; of course, if and how that's done is no longer our (the ASF
project's) problem, as long as they adhere to the "principle of least
surprise," q.v. above.

>> 'gridgain-ignite'? There's no such thing.
>> Really, I thought we had the brand dilution and trademark violation
>> questions sorted out.
> That's a bad idea, indeed! There shouldn't be such thing as Foo Ignite, where
> Foo != Apache. That's a clear contradiction to TM policy.


-- Brane

View raw message