ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Replacing default work dir from tmp to current dir
Date Tue, 27 Aug 2019 15:28:09 GMT
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 <dpavlov@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 <xxtern@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.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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message