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:57:15 GMT
Hello again!

Please note that I have updated release notes for IGNITE-12057 as well as
added them for my ticket. Release Engineers, please make sure you include
the latest one.

Regards,
-- 
Ilya Kasnacheev


пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev <ilya.kasnacheev@gmail.com>:

> 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