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 > > >
