Hello again! Please note that I have updated release notes for IGNITE-12057 as well as added them for my ticket. Release Engineers, please make sure you include the latest one.
Regards, -- Ilya Kasnacheev пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev <ilya.kasnach...@gmail.com>: > Hello! > > I have pushed an amended fix to both master and ignite-2.7.6. > > Regards, > -- > Ilya Kasnacheev > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda <dma...@apache.org>: > >> Ilya, >> >> I forgot to push "Send for review" button. You can see my minor comment >> now. >> >> - >> Denis >> >> >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >> wrote: >> >> > Hello! >> > >> > Waiting for a minor comment from Denis, as soon as I see/fix it I'm >> going >> > to commit. >> > >> > Regards, >> > Ilya. >> > -- >> > Ilya Kasnacheev >> > >> > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < >> alexey.goncha...@gmail.com >> > >: >> > >> > > Hello Ilya, >> > > >> > > Just curious, when are you planning to commit your changes to the >> 2.7.6 >> > > branch? >> > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda <dma...@apache.org>: >> > > >> > > > Ok, seems like we came to a consensus. Let’s ensure that the path >> for >> > our >> > > > work dir is user.dir/ignite/work and restart the vote. >> > > > >> > > > Denis >> > > > >> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < >> > ilya.kasnach...@gmail.com> >> > > > wrote: >> > > > >> > > > > Hello! >> > > > > >> > > > > I have took the liberty to implement the change to existing code >> base >> > > to >> > > > > remove concern about work/ directory: >> > > > > >> > > > > https://github.com/apache/ignite/pull/6816/files >> > > > > >> > > > > Some advocacy for this patch: >> > > > > - Minimal change. >> > > > > - Storing in user.dir/ignite/work (current directory, e.g. project >> > > root) >> > > > > which is consistent with behavior of unzipped binary release. >> > > > > - We can re-use user.dir/ignite for other uses in the future, >> such as >> > > > > storing logs there. >> > > > > >> > > > > I have to admit that my previous reaction to the change was too >> > strong. >> > > > It >> > > > > turned out the default was user.dir/work (project root) and not >> > > > > user.home/work (home dir with imminent Work collision). >> > > > > Nevertheless, I think that after this change it would be good >> enough >> > to >> > > > > last for a few years. >> > > > > >> > > > > What do you think? >> > > > > >> > > > > Regards, >> > > > > -- >> > > > > Ilya Kasnacheev >> > > > > >> > > > > >> > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < >> > > > alexey.goncha...@gmail.com >> > > > > >: >> > > > > >> > > > > > In the current state of the project, we cannot directly compare >> > > Ignite >> > > > > > setup process to the one of postgresql or another database. In >> many >> > > > > Ignite >> > > > > > examples, an embedded node (even with persistence) is started >> and >> > it >> > > is >> > > > > > supposed to run without any additional FS rights grants or init >> > > steps. >> > > > > This >> > > > > > may be changed in 3.0, but not in a maintenance release. If we >> are >> > to >> > > > > > change the directory to /var/lib, I would rather fail Ignite >> node >> > > start >> > > > > > asking a user to explicitly provide work directory path. Let >> alone >> > > > > /var/lib >> > > > > > is not portable and I would not add an OS-switch to the code >> for no >> > > > > reason. >> > > > > > >> > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya >> that >> > > > > writing >> > > > > > large amounts of data in a hidden folder is a bad idea. >> > > > > > >> > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov <dpav...@apache.org >> >: >> > > > > > >> > > > > > > Hi Igniters, >> > > > > > > >> > > > > > > I agree that user home maybe not the best place from Linux >> > > > perspective >> > > > > > and >> > > > > > > philosophy, but "user.home"/ignite/work is more or less >> > portable. >> > > > > > > >> > > > > > > For the Linux environment, we can add a suggestion about >> where to >> > > > place >> > > > > > > persisted data. For very first testing of Apache Ignite user >> home >> > > > still >> > > > > > > looks good for me. >> > > > > > > >> > > > > > > Sincerely, >> > > > > > > Dmitriy Pavlov >> > > > > > > >> > > > > > > вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin < >> xxt...@gmail.com >> > >: >> > > > > > > >> > > > > > > > Or instead of a WARNING, we can add a suggestion with a >> > > > > recommendation >> > > > > > > > for the production environment. >> > > > > > > > >> > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov < >> mr.wei...@gmail.com >> > >: >> > > > > > > > > >> > > > > > > > > /opt is either does not exist on fresh system, or has the >> > same >> > > > > > > > restriction: no user access without admin intervention. >> > > > > > > > > /usr/local, /var/lib, etc. — all this is implemented in >> our >> > > DEB / >> > > > > RPM >> > > > > > > > packages already. >> > > > > > > > > >> > > > > > > > > For ZIP installation %HOME% seems to be the best approach >> for >> > > > > > "2-click" >> > > > > > > > launch. >> > > > > > > > > Later user can update preferences and set working dir to >> > > whatever >> > > > > > > > directory he would like. >> > > > > > > > > >> > > > > > > > > Also — we can put WARNING message to log noting that >> WORK_DIR >> > > is >> > > > > set >> > > > > > to >> > > > > > > > default. >> > > > > > > > > >> > > > > > > > > > On 27 Aug 2019, at 10:16, Zhenya Stanilovsky >> > > > > > > > <arzamas...@mail.ru.INVALID> wrote: >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > And what about /opt/ignite ? >> > > > > > > > > > >> > > > > > > > > > copy-paste: >> > > > > > > > > > " >> > > > > > > > > > The basic difference is that /usr/local is for >> software >> > not >> > > > > > managed >> > > > > > > > by the system packager, but still following the standard >> unix >> > > > > > deployment >> > > > > > > > rules. >> > > > > > > > > > That's why you have /usr/local/bin , /usr/local/sbin >> > > > > > > > /usr/local/include etc... >> > > > > > > > > > /opt on the other hand is for software that doesn't >> follow >> > > > this >> > > > > > and >> > > > > > > > is deployed in a monolithic fashion. This usually includes >> > > > commercial >> > > > > > > > and/or cross-platform software that is packaged in the >> > "Windows" >> > > > > > style. " >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis >> Magda >> > < >> > > > > > > > dma...@apache.org>: >> > > > > > > > > >> >> > > > > > > > > >> Igniters, >> > > > > > > > > >> >> > > > > > > > > >> I can't disagree with Nikolay that, as a database, >> Ignite >> > > > needs >> > > > > to >> > > > > > > > persist >> > > > > > > > > >> changes to a folder different from "user.home" one. But >> > with >> > > > the >> > > > > > > > current >> > > > > > > > > >> rate of project growth and adoption, I would encourage >> us >> > to >> > > > > > > > eliminate any >> > > > > > > > > >> possible obstacles a user might come across during the >> > > getting >> > > > > > > started >> > > > > > > > > >> phase with Ignite. Unfortunately, folders different >> from >> > > > > > "user.home" >> > > > > > > > imply >> > > > > > > > > >> a significant restriction - the user needs to allow >> access >> > > to >> > > > > > > folders >> > > > > > > > like >> > > > > > > > > >> /lib, /etc; which can make every getting started demo >> or >> > app >> > > > > fail. >> > > > > > > > > >> >> > > > > > > > > >> Thus, today, I'm casting my vote for >> > "user.home"/ignite/work >> > > > > > > > directory. >> > > > > > > > > >> Please don't forget about Windows and MacOS. >> > > > > > > > > >> >> > > > > > > > > >> - >> > > > > > > > > >> Denis >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > > > >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < >> > > > > > > ptupit...@apache.org >> > > > > > > > > wrote: >> > > > > > > > > >> >> > > > > > > > > >>> +1 for ~/.ignite/work >> > > > > > > > > >>> >> > > > > > > > > >>> As Petr mentioned above, this translates well to >> Windows >> > > and >> > > > > > MacOS >> > > > > > > > too, we >> > > > > > > > > >>> can use "home directory" term in documentation and it >> > works >> > > > for >> > > > > > any >> > > > > > > > OS. >> > > > > > > > > >>> >> > > > > > > > > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < >> > > > > > > > nizhi...@apache.org > >> > > > > > > > > >>> wrote: >> > > > > > > > > >>> >> > > > > > > > > >>>> AFAIK server admin expects software will store it's >> data >> > > in >> > > > > > /var/ >> > > > > > > > > >>>> directory, not in /home directory. >> > > > > > > > > >>>> >> > > > > > > > > >>>>> In Docker age, packages are becoming extinct. >> > > > > > > > > >>>> >> > > > > > > > > >>>> I don't agree with that, but seems, it's not a >> subject >> > of >> > > > > > > > discussion. :) >> > > > > > > > > >>>> >> > > > > > > > > >>>>> we don't even have very good packages today >> > > > > > > > > >>>> >> > > > > > > > > >>>> Why do you think we don't have good packages? >> > > > > > > > > >>>> What is wrong with the current one? >> > > > > > > > > >>>> >> > > > > > > > > >>>>> I also think we should not copy what other DBMS do >> > since >> > > > > their >> > > > > > > > > >>>> ease-of-use >> > > > > > > > > >>>>> is usually lacking >> > > > > > > > > >>>> >> > > > > > > > > >>>> We should define 'easy-of-use' here. >> > > > > > > > > >>>> My experience with the modern dbms(postgres and >> mysql) >> > is >> > > > > > > different. >> > > > > > > > > >>>> >> > > > > > > > > >>>> >> > > > > > > > > >>>> В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev >> пишет: >> > > > > > > > > >>>>> Hello! >> > > > > > > > > >>>>> >> > > > > > > > > >>>>> I think it is 2., because if a node is run from >> Ignite >> > > > binary >> > > > > > > > > >>>> distribution >> > > > > > > > > >>>>> it has its root as a ignite work directory. I think >> it >> > it >> > > > > > another >> > > > > > > > > >>>> argument >> > > > > > > > > >>>>> for keeping data under current dir - Ignite binary >> > > > > distribution >> > > > > > > > already >> > > > > > > > > >>>>> does it, why should embedded scenario be different? >> > > > > > > > > >>>>> >> > > > > > > > > >>>>> In Docker age, packages are becoming extinct. Nobody >> > > wants >> > > > > them >> > > > > > > > > >>> anymore, >> > > > > > > > > >>>>> anyway. I don't see why we should aim for those >> since >> > we >> > > > > don't >> > > > > > > even >> > > > > > > > > >>> have >> > > > > > > > > >>>>> very good packages today, and nobody wants to >> > contribute >> > > > > > towards >> > > > > > > > their >> > > > > > > > > >>>>> improvement. >> > > > > > > > > >>>>> >> > > > > > > > > >>>>> I also think we should not copy what other DBMS do >> > since >> > > > > their >> > > > > > > > > >>>> ease-of-use >> > > > > > > > > >>>>> is usually lacking (this is from someone who had to >> > > support >> > > > > > mysql >> > > > > > > > and >> > > > > > > > > >>>> pgsql >> > > > > > > > > >>>>> deployments). >> > > > > > > > > >>>>> >> > > > > > > > > >>>>> Regards, >> > > > > > > > > >>>> >> > > > > > > > > >>> >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > -- >> > > > > > > > > > Zhenya Stanilovsky >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > -- >> > > > - >> > > > Denis >> > > > >> > > >> > >> >
