ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Replacing default work dir from tmp to current dir
Date Tue, 27 Aug 2019 15:43:24 GMT
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.goncharuk@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 <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