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 >
