Denis, we have 2 more tickets to fix before voting: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
ср, 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 >
