Replacing default work dir from tmp to current dir

[Nikolay Izhikov-2]

+1 for '/var/lib/ignite'

В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:

> +1 for '~/.ignite/work'
>
> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <[hidden email]>:
>
> > Hello, Igniters.
> >
> > There are a lot of variants was already proposed lets vote to one of them.
> > I made a list of possible paths which was mentioned earlier. I also
> > included variants outside of home directory('user.dir') to this list but I
> > want to notes that we had already discussed it and we decided to choose
> > some path in home directory rather outside of that. Also If you have any
> > other variants feel free to add it.
> >
> > 1) ~/.ignite/work
> > 2) ~/ignite/work
> > 3) ~/.config/ignite/work
> >
> > 4)/var/lib/ignite
> > 5)/usr/local/ignite
> > 6)/var/ignite
> > 7)/var/lib/ignite
> > 8)/opt/ignite/
> >
> > +1 for '~/.ignite/work'
> >
> > --
> > Best regards,
> > Anton Kalashnikov
> >
> >
> > 26.08.2019, 12:39, "Nikolay Izhikov" <[hidden email]>:
> > > Ilya,
> > >
> > > >  In development environment one can just run Java from /var/lib/ignite
> > >
> > > Actually, I doesn't understand you.
> > > Are you talking about development of some application that uses Ignite
> >
> > or contribution to Ignite code base?
> > >
> > > If we are talking about some application that uses Ignite then we should
> >
> > decide, which scenario is primary.
> > > (One more time, we are talking about PDS enabled caches):
> > >
> > > 1. Ignite server node started as separate java process.
> > > 2. Ignite server node embedded in application as a library.
> > >
> > > I think, for PDS enabled cashes first case is primary.
> > > In that case, user should install Ignite via some package(deb, rpm,
> >
> > docker, etc).
> > > This package should done all required configuration.
> > > Including directory permissions.
> > >
> > > This should be done like other DBMS do.
> > >
> > > If we are talking about embedded Ignite then we can ask the user to
> >
> > provide sufficient permission for default dir or change dir to some other.
> > >
> > > So, I still think we should use /var/lig/ignite for PDS data.
> > >
> > > How it sounds?
> > >
> > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > >  Hello!
> > > >
> > > >  In development environment one can just run Java from /var/lib/ignite
> > > >  (makes total sense) and will immediately get almost correct behavior
> >
> > (well,
> > > >  data will be stored to /var/lib/ignite/ignite/work)
> > > >
> > > >  However, I still think that we should write to user.dir/ignite and not
> >
> > just
> > > >  user.dir since current directory is often crowded.
> > > >
> > > >  Fellows, anyone who is against using user.dir? Please share your
> >
> > concerns.
> > > >
> > > >  Regards,
> >
> >

[vveider]

Does this parameters intended to be overridden (for tests purposes for example) or it will be permanently sticked to this new directory without ability to change?

> On 26 Aug 2019, at 13:58, Nikolay Izhikov <[hidden email]> wrote:
>
> +1 for '/var/lib/ignite'
>
> В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
>> +1 for '~/.ignite/work'
>>
>> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <[hidden email]>:
>>
>>> Hello, Igniters.
>>>
>>> There are a lot of variants was already proposed lets vote to one of them.
>>> I made a list of possible paths which was mentioned earlier. I also
>>> included variants outside of home directory('user.dir') to this list but I
>>> want to notes that we had already discussed it and we decided to choose
>>> some path in home directory rather outside of that. Also If you have any
>>> other variants feel free to add it.
>>>
>>> 1) ~/.ignite/work
>>> 2) ~/ignite/work
>>> 3) ~/.config/ignite/work
>>>
>>> 4)/var/lib/ignite
>>> 5)/usr/local/ignite
>>> 6)/var/ignite
>>> 7)/var/lib/ignite
>>> 8)/opt/ignite/
>>>
>>> +1 for '~/.ignite/work'
>>>
>>> --
>>> Best regards,
>>> Anton Kalashnikov
>>>
>>>
>>> 26.08.2019, 12:39, "Nikolay Izhikov" <[hidden email]>:
>>>> Ilya,
>>>>
>>>>> In development environment one can just run Java from /var/lib/ignite
>>>>
>>>> Actually, I doesn't understand you.
>>>> Are you talking about development of some application that uses Ignite
>>>
>>> or contribution to Ignite code base?
>>>>
>>>> If we are talking about some application that uses Ignite then we should
>>>
>>> decide, which scenario is primary.
>>>> (One more time, we are talking about PDS enabled caches):
>>>>
>>>> 1. Ignite server node started as separate java process.
>>>> 2. Ignite server node embedded in application as a library.
>>>>
>>>> I think, for PDS enabled cashes first case is primary.
>>>> In that case, user should install Ignite via some package(deb, rpm,
>>>
>>> docker, etc).
>>>> This package should done all required configuration.
>>>> Including directory permissions.
>>>>
>>>> This should be done like other DBMS do.
>>>>
>>>> If we are talking about embedded Ignite then we can ask the user to
>>>
>>> provide sufficient permission for default dir or change dir to some other.
>>>>
>>>> So, I still think we should use /var/lig/ignite for PDS data.
>>>>
>>>> How it sounds?
>>>>
>>>> В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
>>>>> Hello!
>>>>>
>>>>> In development environment one can just run Java from /var/lib/ignite
>>>>> (makes total sense) and will immediately get almost correct behavior
>>>
>>> (well,
>>>>> data will be stored to /var/lib/ignite/ignite/work)
>>>>>
>>>>> However, I still think that we should write to user.dir/ignite and not
>>>
>>> just
>>>>> user.dir since current directory is often crowded.
>>>>>
>>>>> Fellows, anyone who is against using user.dir? Please share your
>>>
>>> concerns.
>>>>>
>>>>> Regards,
>>>
>>>

[Nikolay Izhikov-2]

Yes, of course.

В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:

> Does this parameters intended to be overridden (for tests purposes for example) or it will be permanently sticked to this new directory without ability to change?
>
>
> > On 26 Aug 2019, at 13:58, Nikolay Izhikov <[hidden email]> wrote:
> >
> > +1 for '/var/lib/ignite'
> >
> > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > +1 for '~/.ignite/work'
> > >
> > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <[hidden email]>:
> > >
> > > > Hello, Igniters.
> > > >
> > > > There are a lot of variants was already proposed lets vote to one of them.
> > > > I made a list of possible paths which was mentioned earlier. I also
> > > > included variants outside of home directory('user.dir') to this list but I
> > > > want to notes that we had already discussed it and we decided to choose
> > > > some path in home directory rather outside of that. Also If you have any
> > > > other variants feel free to add it.
> > > >
> > > > 1) ~/.ignite/work
> > > > 2) ~/ignite/work
> > > > 3) ~/.config/ignite/work
> > > >
> > > > 4)/var/lib/ignite
> > > > 5)/usr/local/ignite
> > > > 6)/var/ignite
> > > > 7)/var/lib/ignite
> > > > 8)/opt/ignite/
> > > >
> > > > +1 for '~/.ignite/work'
> > > >
> > > > --
> > > > Best regards,
> > > > Anton Kalashnikov
> > > >
> > > >
> > > > 26.08.2019, 12:39, "Nikolay Izhikov" <[hidden email]>:
> > > > > Ilya,
> > > > >
> > > > > > In development environment one can just run Java from /var/lib/ignite
> > > > >
> > > > > Actually, I doesn't understand you.
> > > > > Are you talking about development of some application that uses Ignite
> > > >
> > > > or contribution to Ignite code base?
> > > > >
> > > > > If we are talking about some application that uses Ignite then we should
> > > >
> > > > decide, which scenario is primary.
> > > > > (One more time, we are talking about PDS enabled caches):
> > > > >
> > > > > 1. Ignite server node started as separate java process.
> > > > > 2. Ignite server node embedded in application as a library.
> > > > >
> > > > > I think, for PDS enabled cashes first case is primary.
> > > > > In that case, user should install Ignite via some package(deb, rpm,
> > > >
> > > > docker, etc).
> > > > > This package should done all required configuration.
> > > > > Including directory permissions.
> > > > >
> > > > > This should be done like other DBMS do.
> > > > >
> > > > > If we are talking about embedded Ignite then we can ask the user to
> > > >
> > > > provide sufficient permission for default dir or change dir to some other.
> > > > >
> > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > >
> > > > > How it sounds?
> > > > >
> > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > Hello!
> > > > > >
> > > > > > In development environment one can just run Java from /var/lib/ignite
> > > > > > (makes total sense) and will immediately get almost correct behavior
> > > >
> > > > (well,
> > > > > > data will be stored to /var/lib/ignite/ignite/work)
> > > > > >
> > > > > > However, I still think that we should write to user.dir/ignite and not
> > > >
> > > > just
> > > > > > user.dir since current directory is often crowded.
> > > > > >
> > > > > > Fellows, anyone who is against using user.dir? Please share your
> > > >
> > > > concerns.
> > > > > >
> > > > > > Regards,
> > > >
> > > >
>
>

[Mmuzaf]

Folks,

According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
the ideal reference), the `/var/lib` directory is the `state
information. Persistent data modified by programs as they run, e.g.,
databases, packaging system metadata, etc.`

So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.

[1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov <[hidden email]> wrote:

>
> Yes, of course.
>
> В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
> > Does this parameters intended to be overridden (for tests purposes for example) or it will be permanently sticked to this new directory without ability to change?
> >
> >
> > > On 26 Aug 2019, at 13:58, Nikolay Izhikov <[hidden email]> wrote:
> > >
> > > +1 for '/var/lib/ignite'
> > >
> > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > +1 for '~/.ignite/work'
> > > >
> > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <[hidden email]>:
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > There are a lot of variants was already proposed lets vote to one of them.
> > > > > I made a list of possible paths which was mentioned earlier. I also
> > > > > included variants outside of home directory('user.dir') to this list but I
> > > > > want to notes that we had already discussed it and we decided to choose
> > > > > some path in home directory rather outside of that. Also If you have any
> > > > > other variants feel free to add it.
> > > > >
> > > > > 1) ~/.ignite/work
> > > > > 2) ~/ignite/work
> > > > > 3) ~/.config/ignite/work
> > > > >
> > > > > 4)/var/lib/ignite
> > > > > 5)/usr/local/ignite
> > > > > 6)/var/ignite
> > > > > 7)/var/lib/ignite
> > > > > 8)/opt/ignite/
> > > > >
> > > > > +1 for '~/.ignite/work'
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Anton Kalashnikov
> > > > >
> > > > >
> > > > > 26.08.2019, 12:39, "Nikolay Izhikov" <[hidden email]>:
> > > > > > Ilya,
> > > > > >
> > > > > > > In development environment one can just run Java from /var/lib/ignite
> > > > > >
> > > > > > Actually, I doesn't understand you.
> > > > > > Are you talking about development of some application that uses Ignite
> > > > >
> > > > > or contribution to Ignite code base?
> > > > > >
> > > > > > If we are talking about some application that uses Ignite then we should
> > > > >
> > > > > decide, which scenario is primary.
> > > > > > (One more time, we are talking about PDS enabled caches):
> > > > > >
> > > > > > 1. Ignite server node started as separate java process.
> > > > > > 2. Ignite server node embedded in application as a library.
> > > > > >
> > > > > > I think, for PDS enabled cashes first case is primary.
> > > > > > In that case, user should install Ignite via some package(deb, rpm,
> > > > >
> > > > > docker, etc).
> > > > > > This package should done all required configuration.
> > > > > > Including directory permissions.
> > > > > >
> > > > > > This should be done like other DBMS do.
> > > > > >
> > > > > > If we are talking about embedded Ignite then we can ask the user to
> > > > >
> > > > > provide sufficient permission for default dir or change dir to some other.
> > > > > >
> > > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > > >
> > > > > > How it sounds?
> > > > > >
> > > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > > Hello!
> > > > > > >
> > > > > > > In development environment one can just run Java from /var/lib/ignite
> > > > > > > (makes total sense) and will immediately get almost correct behavior
> > > > >
> > > > > (well,
> > > > > > > data will be stored to /var/lib/ignite/ignite/work)
> > > > > > >
> > > > > > > However, I still think that we should write to user.dir/ignite and not
> > > > >
> > > > > just
> > > > > > > user.dir since current directory is often crowded.
> > > > > > >
> > > > > > > Fellows, anyone who is against using user.dir? Please share your
> > > > >
> > > > > concerns.
> > > > > > >
> > > > > > > Regards,
> > > > >
> > > > >
> >
> >

[Dmitry Pavlov]

Ok, folks, I'm not insisting on
~/ignite/work nor ~/.ignite/work

I wondering what about Windows systems. Linux is not only one platform
Ignite runs on.

пн, 26 авг. 2019 г. в 14:28, Maxim Muzafarov <[hidden email]>:

> Folks,
>
> According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
> the ideal reference), the `/var/lib` directory is the `state
> information. Persistent data modified by programs as they run, e.g.,
> databases, packaging system metadata, etc.`
>
> So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.
>
> [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>
> On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov <[hidden email]> wrote:
> >
> > Yes, of course.
> >
> > В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
> > > Does this parameters intended to be overridden (for tests purposes for
> example) or it will be permanently sticked to this new directory without
> ability to change?
> > >
> > >
> > > > On 26 Aug 2019, at 13:58, Nikolay Izhikov <[hidden email]>
> wrote:
> > > >
> > > > +1 for '/var/lib/ignite'
> > > >
> > > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > > +1 for '~/.ignite/work'
> > > > >
> > > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <[hidden email]
> >:
> > > > >
> > > > > > Hello, Igniters.
> > > > > >
> > > > > > There are a lot of variants was already proposed lets vote to
> one of them.
> > > > > > I made a list of possible paths which was mentioned earlier. I
> also
> > > > > > included variants outside of home directory('user.dir') to this
> list but I
> > > > > > want to notes that we had already discussed it and we decided to
> choose
> > > > > > some path in home directory rather outside of that. Also If you
> have any
> > > > > > other variants feel free to add it.
> > > > > >
> > > > > > 1) ~/.ignite/work
> > > > > > 2) ~/ignite/work
> > > > > > 3) ~/.config/ignite/work
> > > > > >
> > > > > > 4)/var/lib/ignite
> > > > > > 5)/usr/local/ignite
> > > > > > 6)/var/ignite
> > > > > > 7)/var/lib/ignite
> > > > > > 8)/opt/ignite/
> > > > > >
> > > > > > +1 for '~/.ignite/work'
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Anton Kalashnikov
> > > > > >
> > > > > >
> > > > > > 26.08.2019, 12:39, "Nikolay Izhikov" <[hidden email]>:
> > > > > > > Ilya,
> > > > > > >
> > > > > > > > In development environment one can just run Java from
> /var/lib/ignite
> > > > > > >
> > > > > > > Actually, I doesn't understand you.
> > > > > > > Are you talking about development of some application that
> uses Ignite
> > > > > >
> > > > > > or contribution to Ignite code base?
> > > > > > >
> > > > > > > If we are talking about some application that uses Ignite then
> we should
> > > > > >
> > > > > > decide, which scenario is primary.
> > > > > > > (One more time, we are talking about PDS enabled caches):
> > > > > > >
> > > > > > > 1. Ignite server node started as separate java process.
> > > > > > > 2. Ignite server node embedded in application as a library.
> > > > > > >
> > > > > > > I think, for PDS enabled cashes first case is primary.
> > > > > > > In that case, user should install Ignite via some package(deb,
> rpm,
> > > > > >
> > > > > > docker, etc).
> > > > > > > This package should done all required configuration.
> > > > > > > Including directory permissions.
> > > > > > >
> > > > > > > This should be done like other DBMS do.
> > > > > > >
> > > > > > > If we are talking about embedded Ignite then we can ask the
> user to
> > > > > >
> > > > > > provide sufficient permission for default dir or change dir to
> some other.
> > > > > > >
> > > > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > > > >
> > > > > > > How it sounds?
> > > > > > >
> > > > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > In development environment one can just run Java from
> /var/lib/ignite
> > > > > > > > (makes total sense) and will immediately get almost correct
> behavior
> > > > > >
> > > > > > (well,
> > > > > > > > data will be stored to /var/lib/ignite/ignite/work)
> > > > > > > >
> > > > > > > > However, I still think that we should write to
> user.dir/ignite and not
> > > > > >
> > > > > > just
> > > > > > > > user.dir since current directory is often crowded.
> > > > > > > >
> > > > > > > > Fellows, anyone who is against using user.dir? Please share
> your
> > > > > >
> > > > > > concerns.
> > > > > > > >
> > > > > > > > Regards,
> > > > > >
> > > > > >
> > >
> > >
>

[Ilya Kasnacheev]

Hello!

Using /var/lib/ignite guarantees that any persistent Ignite node in
development will immediately fail with a cryptic message upon start, since
/var/lib is not writable by non-privileged users.

If our point is to force user to specify workDirectory setting, then yes,
this makes total sense. However, this seems like a too large breaking
change for a maintenance release.

LTS is not targeted on software developers, rather on package writers who
usually make sure that /var/lib/ignite exists, with correct permissions,
before trying to write there. And, I would add, LTS becomes obsolete as
containerization progresses since dockerized images no longer care deeply
about FS hierarchy.

Regards,
--
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 14:41, Dmitriy Pavlov <[hidden email]>:

> Ok, folks, I'm not insisting on
> ~/ignite/work nor ~/.ignite/work
>
> I wondering what about Windows systems. Linux is not only one platform
> Ignite runs on.
>
> пн, 26 авг. 2019 г. в 14:28, Maxim Muzafarov <[hidden email]>:
>
> > Folks,
> >
> > According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
> > the ideal reference), the `/var/lib` directory is the `state
> > information. Persistent data modified by programs as they run, e.g.,
> > databases, packaging system metadata, etc.`
> >
> > So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.
> >
> > [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> >
> > On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov <[hidden email]>
> wrote:
> > >
> > > Yes, of course.
> > >
> > > В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
> > > > Does this parameters intended to be overridden (for tests purposes
> for
> > example) or it will be permanently sticked to this new directory without
> > ability to change?
> > > >
> > > >
> > > > > On 26 Aug 2019, at 13:58, Nikolay Izhikov <[hidden email]>
> > wrote:
> > > > >
> > > > > +1 for '/var/lib/ignite'
> > > > >
> > > > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > > > +1 for '~/.ignite/work'
> > > > > >
> > > > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <
> [hidden email]
> > >:
> > > > > >
> > > > > > > Hello, Igniters.
> > > > > > >
> > > > > > > There are a lot of variants was already proposed lets vote to
> > one of them.
> > > > > > > I made a list of possible paths which was mentioned earlier. I
> > also
> > > > > > > included variants outside of home directory('user.dir') to this
> > list but I
> > > > > > > want to notes that we had already discussed it and we decided
> to
> > choose
> > > > > > > some path in home directory rather outside of that. Also If you
> > have any
> > > > > > > other variants feel free to add it.
> > > > > > >
> > > > > > > 1) ~/.ignite/work
> > > > > > > 2) ~/ignite/work
> > > > > > > 3) ~/.config/ignite/work
> > > > > > >
> > > > > > > 4)/var/lib/ignite
> > > > > > > 5)/usr/local/ignite
> > > > > > > 6)/var/ignite
> > > > > > > 7)/var/lib/ignite
> > > > > > > 8)/opt/ignite/
> > > > > > >
> > > > > > > +1 for '~/.ignite/work'
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Anton Kalashnikov
> > > > > > >
> > > > > > >
> > > > > > > 26.08.2019, 12:39, "Nikolay Izhikov" <[hidden email]>:
> > > > > > > > Ilya,
> > > > > > > >
> > > > > > > > > In development environment one can just run Java from
> > /var/lib/ignite
> > > > > > > >
> > > > > > > > Actually, I doesn't understand you.
> > > > > > > > Are you talking about development of some application that
> > uses Ignite
> > > > > > >
> > > > > > > or contribution to Ignite code base?
> > > > > > > >
> > > > > > > > If we are talking about some application that uses Ignite
> then
> > we should
> > > > > > >
> > > > > > > decide, which scenario is primary.
> > > > > > > > (One more time, we are talking about PDS enabled caches):
> > > > > > > >
> > > > > > > > 1. Ignite server node started as separate java process.
> > > > > > > > 2. Ignite server node embedded in application as a library.
> > > > > > > >
> > > > > > > > I think, for PDS enabled cashes first case is primary.
> > > > > > > > In that case, user should install Ignite via some
> package(deb,
> > rpm,
> > > > > > >
> > > > > > > docker, etc).
> > > > > > > > This package should done all required configuration.
> > > > > > > > Including directory permissions.
> > > > > > > >
> > > > > > > > This should be done like other DBMS do.
> > > > > > > >
> > > > > > > > If we are talking about embedded Ignite then we can ask the
> > user to
> > > > > > >
> > > > > > > provide sufficient permission for default dir or change dir to
> > some other.
> > > > > > > >
> > > > > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > > > > >
> > > > > > > > How it sounds?
> > > > > > > >
> > > > > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > In development environment one can just run Java from
> > /var/lib/ignite
> > > > > > > > > (makes total sense) and will immediately get almost correct
> > behavior
> > > > > > >
> > > > > > > (well,
> > > > > > > > > data will be stored to /var/lib/ignite/ignite/work)
> > > > > > > > >
> > > > > > > > > However, I still think that we should write to
> > user.dir/ignite and not
> > > > > > >
> > > > > > > just
> > > > > > > > > user.dir since current directory is often crowded.
> > > > > > > > >
> > > > > > > > > Fellows, anyone who is against using user.dir? Please share
> > your
> > > > > > >
> > > > > > > concerns.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > >
> > > > > > >
> > > >
> > > >
> >
>

[Nikolay Izhikov-2]

Hello, Ilya.

We can't have discussion if you only make statements, but don't answer the questions :)
I repeat my own statements and questions to you.

*How do you think, what is primary usage scenario for Ignite with PDS enabled cache?*

If we are talking about some application that uses Ignite then we should decide, which scenario is primary.
(One more time, we are talking about PDS enabled caches):

1. Ignite server node started as separate java process.
2. Ignite server node embedded in application as a library.

I think, for PDS enabled cashes first case is primary.
In that case, user should install Ignite via some package(deb, rpm, docker, etc).
This package should done all required configuration.
Including directory permissions.

This should be done like other DBMS do.

If we are talking about embedded Ignite then we can ask the user to provide sufficient permission for default dir or change dir to some other.

So, I still think we should use /var/lig/ignite for PDS data.

How it sounds?




В Пн, 26/08/2019 в 15:24 +0300, Ilya Kasnacheev пишет:

> Hello!
>
> Using /var/lib/ignite guarantees that any persistent Ignite node in
> development will immediately fail with a cryptic message upon start, since
> /var/lib is not writable by non-privileged users.
>
> If our point is to force user to specify workDirectory setting, then yes,
> this makes total sense. However, this seems like a too large breaking
> change for a maintenance release.
>
> LTS is not targeted on software developers, rather on package writers who
> usually make sure that /var/lib/ignite exists, with correct permissions,
> before trying to write there. And, I would add, LTS becomes obsolete as
> containerization progresses since dockerized images no longer care deeply
> about FS hierarchy.
>
> Regards,

[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,
--
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 15:27, Nikolay Izhikov <[hidden email]>:

> Hello, Ilya.
>
> We can't have discussion if you only make statements, but don't answer the
> questions :)
> I repeat my own statements and questions to you.
>
> *How do you think, what is primary usage scenario for Ignite with PDS
> enabled cache?*
>
> If we are talking about some application that uses Ignite then we should
> decide, which scenario is primary.
> (One more time, we are talking about PDS enabled caches):
>
> 1. Ignite server node started as separate java process.
> 2. Ignite server node embedded in application as a library.
>
> I think, for PDS enabled cashes first case is primary.
> In that case, user should install Ignite via some package(deb, rpm,
> docker, etc).
> This package should done all required configuration.
> Including directory permissions.
>
> This should be done like other DBMS do.
>
> If we are talking about embedded Ignite then we can ask the user to
> provide sufficient permission for default dir or change dir to some other.
>
> So, I still think we should use /var/lig/ignite for PDS data.
>
> How it sounds?
>
>
>
>
> В Пн, 26/08/2019 в 15:24 +0300, Ilya Kasnacheev пишет:
> > Hello!
> >
> > Using /var/lib/ignite guarantees that any persistent Ignite node in
> > development will immediately fail with a cryptic message upon start,
> since
> > /var/lib is not writable by non-privileged users.
> >
> > If our point is to force user to specify workDirectory setting, then yes,
> > this makes total sense. However, this seems like a too large breaking
> > change for a maintenance release.
> >
> > LTS is not targeted on software developers, rather on package writers who
> > usually make sure that /var/lib/ignite exists, with correct permissions,
> > before trying to write there. And, I would add, LTS becomes obsolete as
> > containerization progresses since dockerized images no longer care deeply
> > about FS hierarchy.
> >
> > Regards,
>

[vveider]

In Windows there is %USER%/Application Data folder (or just %USER%) that is analog of ~/. in Linux.
MacOS has home directory as well, so that should not be a problem.

> On 26 Aug 2019, at 14:41, Dmitriy Pavlov <[hidden email]> wrote:
>
> Ok, folks, I'm not insisting on
> ~/ignite/work nor ~/.ignite/work
>
> I wondering what about Windows systems. Linux is not only one platform
> Ignite runs on.
>
> пн, 26 авг. 2019 г. в 14:28, Maxim Muzafarov <[hidden email]>:
>
>> Folks,
>>
>> According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
>> the ideal reference), the `/var/lib` directory is the `state
>> information. Persistent data modified by programs as they run, e.g.,
>> databases, packaging system metadata, etc.`
>>
>> So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.
>>
>> [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>>
>> On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov <[hidden email]> wrote:
>>>
>>> Yes, of course.
>>>
>>> В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
>>>> Does this parameters intended to be overridden (for tests purposes for
>> example) or it will be permanently sticked to this new directory without
>> ability to change?
>>>>
>>>>
>>>>> On 26 Aug 2019, at 13:58, Nikolay Izhikov <[hidden email]>
>> wrote:
>>>>>
>>>>> +1 for '/var/lib/ignite'
>>>>>
>>>>> В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
>>>>>> +1 for '~/.ignite/work'
>>>>>>
>>>>>> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <[hidden email]
>>> :
>>>>>>
>>>>>>> Hello, Igniters.
>>>>>>>
>>>>>>> There are a lot of variants was already proposed lets vote to
>> one of them.
>>>>>>> I made a list of possible paths which was mentioned earlier. I
>> also
>>>>>>> included variants outside of home directory('user.dir') to this
>> list but I
>>>>>>> want to notes that we had already discussed it and we decided to
>> choose
>>>>>>> some path in home directory rather outside of that. Also If you
>> have any
>>>>>>> other variants feel free to add it.
>>>>>>>
>>>>>>> 1) ~/.ignite/work
>>>>>>> 2) ~/ignite/work
>>>>>>> 3) ~/.config/ignite/work
>>>>>>>
>>>>>>> 4)/var/lib/ignite
>>>>>>> 5)/usr/local/ignite
>>>>>>> 6)/var/ignite
>>>>>>> 7)/var/lib/ignite
>>>>>>> 8)/opt/ignite/
>>>>>>>
>>>>>>> +1 for '~/.ignite/work'
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Anton Kalashnikov
>>>>>>>
>>>>>>>
>>>>>>> 26.08.2019, 12:39, "Nikolay Izhikov" <[hidden email]>:
>>>>>>>> Ilya,
>>>>>>>>
>>>>>>>>> In development environment one can just run Java from
>> /var/lib/ignite
>>>>>>>>
>>>>>>>> Actually, I doesn't understand you.
>>>>>>>> Are you talking about development of some application that
>> uses Ignite
>>>>>>>
>>>>>>> or contribution to Ignite code base?
>>>>>>>>
>>>>>>>> If we are talking about some application that uses Ignite then
>> we should
>>>>>>>
>>>>>>> decide, which scenario is primary.
>>>>>>>> (One more time, we are talking about PDS enabled caches):
>>>>>>>>
>>>>>>>> 1. Ignite server node started as separate java process.
>>>>>>>> 2. Ignite server node embedded in application as a library.
>>>>>>>>
>>>>>>>> I think, for PDS enabled cashes first case is primary.
>>>>>>>> In that case, user should install Ignite via some package(deb,
>> rpm,
>>>>>>>
>>>>>>> docker, etc).
>>>>>>>> This package should done all required configuration.
>>>>>>>> Including directory permissions.
>>>>>>>>
>>>>>>>> This should be done like other DBMS do.
>>>>>>>>
>>>>>>>> If we are talking about embedded Ignite then we can ask the
>> user to
>>>>>>>
>>>>>>> provide sufficient permission for default dir or change dir to
>> some other.
>>>>>>>>
>>>>>>>> So, I still think we should use /var/lig/ignite for PDS data.
>>>>>>>>
>>>>>>>> How it sounds?
>>>>>>>>
>>>>>>>> В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> In development environment one can just run Java from
>> /var/lib/ignite
>>>>>>>>> (makes total sense) and will immediately get almost correct
>> behavior
>>>>>>>
>>>>>>> (well,
>>>>>>>>> data will be stored to /var/lib/ignite/ignite/work)
>>>>>>>>>
>>>>>>>>> However, I still think that we should write to
>> user.dir/ignite and not
>>>>>>>
>>>>>>> just
>>>>>>>>> user.dir since current directory is often crowded.
>>>>>>>>>
>>>>>>>>> Fellows, anyone who is against using user.dir? Please share
>> your
>>>>>>>
>>>>>>> concerns.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>
>>>>
>>

[Nikolay Izhikov-2]

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,

[Pavel Tupitsyn]

+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 <[hidden email]> 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,
>

[dmagda]

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 <[hidden email]> 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 <[hidden email]>
> 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]

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 <[hidden email]>:
>
>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 < [hidden email] > 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 < [hidden email] >
>> 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

[vveider]

/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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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 < [hidden email] > 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 < [hidden email] >
>>> 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

[Pavel Pereslegin]

Or instead of a WARNING, we can add a suggestion with a recommendation
for the production environment.

вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <[hidden email]>:

>
> /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 <[hidden email]> 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 <[hidden email]>:
> >>
> >> 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 < [hidden email] > 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 < [hidden email] >
> >>> 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
>

[Dmitry Pavlov]

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 <[hidden email]>:

> Or instead of a WARNING, we can add a suggestion with a recommendation
> for the production environment.
>
> вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <[hidden email]>:
> >
> > /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
> <[hidden email]> 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 <
> [hidden email]>:
> > >>
> > >> 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 < [hidden email]
> > 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 <
> [hidden email] >
> > >>> 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
> >
>

[Alexey Goncharuk]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > Or instead of a WARNING, we can add a suggestion with a recommendation
> > for the production environment.
> >
> > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <[hidden email]>:
> > >
> > > /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
> > <[hidden email]> 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 <
> > [hidden email]>:
> > > >>
> > > >> 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 <
> [hidden email]
> > > 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 <
> > [hidden email] >
> > > >>> 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
> > >
> >
>

[Ilya Kasnacheev]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > Or instead of a WARNING, we can add a suggestion with a recommendation
> > > for the production environment.
> > >
> > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <[hidden email]>:
> > > >
> > > > /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
> > > <[hidden email]> 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 <
> > > [hidden email]>:
> > > > >>
> > > > >> 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 <
> > [hidden email]
> > > > 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 <
> > > [hidden email] >
> > > > >>> 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
> > > >
> > >
> >
>

[dmagda]

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 <[hidden email]>
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 <[hidden email]
> >:
>
> > 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > >
> > > > Or instead of a WARNING, we can add a suggestion with a
> recommendation
> > > > for the production environment.
> > > >
> > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <[hidden email]>:
> > > > >
> > > > > /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
> > > > <[hidden email]> 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 <
> > > > [hidden email]>:
> > > > > >>
> > > > > >> 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 <
> > > [hidden email]
> > > > > 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 <
> > > > [hidden email] >
> > > > > >>> 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

[Dmitry Pavlov]

Denis, we have 2 more tickets to fix before voting:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6

ср, 28 авг. 2019 г. в 04:57, Denis Magda <[hidden email]>:

> 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 <[hidden email]>
> 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 <
> [hidden email]
> > >:
> >
> > > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > >
> > > > > Or instead of a WARNING, we can add a suggestion with a
> > recommendation
> > > > > for the production environment.
> > > > >
> > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <[hidden email]>:
> > > > > >
> > > > > > /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
> > > > > <[hidden email]> 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 <
> > > > > [hidden email]>:
> > > > > > >>
> > > > > > >> 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 <
> > > > [hidden email]
> > > > > > 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 <
> > > > > [hidden email] >
> > > > > > >>> 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
>