ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Pereslegin <xxt...@gmail.com>
Subject Re: Replacing default work dir from tmp to current dir
Date Tue, 27 Aug 2019 08:56:17 GMT
Or instead of a WARNING, we can add a suggestion with a recommendation
for the production environment.

вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <mr.weider@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 <arzamas123@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
<dmagda@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 < ptupitsyn@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 < nizhikov@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
>

Mime
View raw message