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 Mon, 02 Sep 2019 10:33:52 GMT
Hello!

I have pushed an amended fix to both master and ignite-2.7.6.

Regards,
-- 
Ilya Kasnacheev


пт, 30 авг. 2019 г. в 21:48, Denis Magda <dmagda@apache.org>:

> Ilya,
>
> I forgot to push "Send for review" button. You can see my minor comment
> now.
>
> -
> Denis
>
>
> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev <ilya.kasnacheev@gmail.com
> >
> wrote:
>
> > Hello!
> >
> > Waiting for a minor comment from Denis, as soon as I see/fix it I'm going
> > to commit.
> >
> > Regards,
> > Ilya.
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk <
> alexey.goncharuk@gmail.com
> > >:
> >
> > > Hello Ilya,
> > >
> > > Just curious, when are you planning to commit your changes to the 2.7.6
> > > branch?
> > >
> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda <dmagda@apache.org>:
> > >
> > > > Ok, seems like we came to a consensus. Let’s ensure that the path for
> > our
> > > > work dir is user.dir/ignite/work and restart the vote.
> > > >
> > > > Denis
> > > >
> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev <
> > ilya.kasnacheev@gmail.com>
> > > > wrote:
> > > >
> > > > > 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > -
> > > > Denis
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message