Raul, Could point about Javascript, it will not work because it executes in the browser. This means we need a server-side script, like CGI we are using on our download page.
How about this approach. We create something like ignite-version.cgi script which will invoke a call to GA and then return the latest version. This should work, right? D. On Fri, Aug 25, 2017 at 2:42 PM, Raúl Kripalani <raul....@evosent.com> wrote: > Hey Dmitriy and all > > Also, since we have GA enabled for the website, we can track how many times > > this page was accessed, which will be equal to the number of starts. This > > way, the counter information is tracked and monitored by the Ignite PMC. > > > Unfortunately this won't work because GA is loaded via Javascript on the > browser, so Google will never receive the page hit. > > Given the constraints, the most viable solution is an HTTPS endpoint > running on ASF infra that Ignite invokes via a GET or POST request. The > simplest thing is to write each request in a log file, along with the > timestamp, the version reported by the client, maybe the IP (not sure about > the ASF rules about this concerning privacy, I guess it's OK if you make it > an opt-in) and a unique node identifier, i.e. a UUID the node creates on > first startup or something. > > This endpoint would need some basic DDoS protection and blacklisting to > prevent data spoofing. > > If we'll be implementing this endpoint anyway, then there's no point > placing another file on Git or elsewhere for reporting the latest versions: > the endpoint itself can return them. > > WDYT? > > Cheers. > > On Fri, Aug 25, 2017 at 9:56 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Cos, Raul, > > > > Thanks for the feedback. I completely agree about Maven Central being a > 3rd > > party repo (did not think about that initially). All your suggestions > make > > sense, but I would like to keep it as simple as possible, and so far > > everything suggested required GIT dependencies and extra work. > > > > How about Yakov's suggestion. We simply add a page to the Ignite website > > which will have only the latest version. Every time a node starts, it > > receives the latest version from the page and suggests that users upgrade > > if needed. > > > > Also, since we have GA enabled for the website, we can track how many > times > > this page was accessed, which will be equal to the number of starts. This > > way, the counter information is tracked and monitored by the Ignite PMC. > > > > This approach looks pretty innocent to me and everything is kept and > > managed within Apache. > > > > Thoughts? > > > > D. > > > > > > On Fri, Aug 25, 2017 at 11:29 AM, Konstantin Boudnik <c...@apache.org> > > wrote: > > > > > I agree with Raul. > > > - providing a ping-back address to a 3rd party might be frown upon by > > some. > > > And might have a consequences like stats collection about users' > > > infrastructure. > > > - checking an ASF git-repo is easy and won't download any binary data: > > > everything is clear text and could be easily monitored by any of the > > > network > > > diagnostic tools, shall it be required. But it involves a bit of the > > > release > > > discipline. > > > - the binary data download in the runtime is my main concern. This is > the > > > vector of MMA. What if someone gains the control over the repository > > and > > > replaces the file with some malicious content. > > > > > > As for the particular mechanism: IIRC Ignite used to make a call to an > > > external script to check upon the atest software version available for > > > download. In the past, the endpoint was running on a 3rd party server, > I > > > believe the best way would be to put this script on ASF infra and have > > the > > > "update checker" running in a completely controlled environment. > > Actually, > > > I > > > recall we had this very discussion during the Incubation; I can > probably > > > dig > > > out the corresponding thread. > > > > > > Thoughts? > > > Cok > > > > > > On Fri, Aug 25, 2017 at 10:41AM, Raul Kripalani wrote: > > > > Hey guys > > > > > > > > In my opinion, maven.org is still owned by a third party (Sonatype). > > We > > > > don't know what kind of data analysis or intelligence extraction they > > > run. > > > > > > > > If Ignite servers all over the world were hitting maven.org > > periodically > > > > asking for an Ignite Maven artifact, it gives Sonatype a clear > > indication > > > > of who is running an Ignite server. > > > > > > > > They could reverse lookup the IP address and find out what > corporation > > it > > > > is. > > > > > > > > How about having Ignite check the ASF Git directly? > > > > > > > > We could use the Git ssh API, but that would require a new > dependency, > > > > which I advise against. > > > > > > > > Alternatively, we could have it scrape this HTML for new Git tags: > > > > https://git-wip-us.apache.org/repos/asf?p=ignite.git > > > > > > > > Another option is to place a txt file in the root of the master > branch > > > (e.g > > > > LATEST), containing a list of the latest GA versions for each major > > > version > > > > line (1.x, 2.x). > > > > > > > > I would advocate this last option, but it requires somebody > remembering > > > to > > > > update the file with every release, unless we automate it with a > Maven > > > > plugin. > > > > > > > > Hope that helps! > > > > > > > > > > > > On 24 Aug 2017 19:37, "Denis Magda" <dma...@apache.org> wrote: > > > > > > > > I see nothing wrong with this approach. > > > > > > > > Cos, Roman, Raul, as Apache veterans, what do you think? Is it good > to > > > go? > > > > > > > > — > > > > Denis > > > > > > > > > On Aug 23, 2017, at 11:17 PM, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > > wrote: > > > > > > > > > > Is everyone OK with this approach? Should I file a ticket on it? > > > > > > > > > > On Mon, Aug 21, 2017 at 2:07 PM, Dmitriy Setrakyan < > > > dsetrak...@apache.org> > > > > > wrote: > > > > > > > > > >> Igniters, > > > > >> > > > > >> There has been lots of talk of proposals about various usage > metrics > > > for > > > > >> Ignite and nothing came of it. I would like to resurrect the topic > > and > > > > >> propose something very simple and non-intrusive. > > > > >> > > > > >> 1. Update Checker > > > > >> The main purpose of the update checker is not to collect metrics, > > but > > > to > > > > >> notify users about a new version of Ignite by accessing maven.org > > and > > > > >> getting the version out of the metadata file: > > > > >> http://repo2.maven.org/maven2/org/apache/ignite/ignite-core/ > > > > >> maven-metadata.xml > > > > >> > > > > >> This way we do not send any information anywhere and, at the same > > > time, > > > > >> urge our users to download and start using the latest version of > > > Ignite. > > > > >> > > > > >> 2. Startup Counter > > > > >> This piece is optional, but we can also get an insight in how many > > > times > > > > a > > > > >> certain Ignite release gets started. This is just a cool metric > for > > > the > > > > >> community to gauge the project popularity. You can think of it as > > of a > > > > page > > > > >> visit counter shown on many websites. We can even decide to > display > > > this > > > > >> counter on the Ignite website as well. > > > > >> > > > > >> To do this, we can simply add a JAR in maven for every release, > e.g. > > > > >> ignite-start-counter.jar, which will contain only 1 byte. Every > time > > > an > > > > >> Ignite node starts, it will download this JAR in the background. > > Then > > > we > > > > >> will be able to view the number of the total downloads for this > JAR > > in > > > > >> Maven Central, which is essentially the number of starts of Ignite > > > nodes. > > > > >> > > > > >> *Note that neither of the above suggestions require Ignite to send > > or > > > > >> track any user information whatsoever.* > > > > >> > > > > >> Please reply suggesting weather you are OK with this approach. > > > > >> > > > > >> D. > > > > >> > > > > > > > > >
