Hello! We are talking about development scenario where you have embedded database in your project and it has to write data somewhere.
/var/lib/ignite is certainly not writable by user's development projects. We could use ~/.config/ignite, which is pure UNIX way today, but I object against potential writing of gigabytes of WAL & PDS into user's .config. ~/ignite and descendants look like a good compromise. Writing to user.dir/ignite, i.e. current work dir, looks equally good. I will create a ticket about it. Regards, -- Ilya Kasnacheev пн, 26 авг. 2019 г. в 11:07, Nikolay Izhikov <nizhi...@apache.org>: > Hello, Igniters. > > There are plenty of options to store application files in linux: > > * /usr/local/ignite > * /var/ignite > * /var/lib/ignite > * ~/.ignite/ > * /opt/ignite/ > > Seems, ~/ignite/work (without a dot in the beginning) is not a Linux-way > naming. > > Postgresql use '/usr/local/pgsql/` > Mysql use '/var/lib/mysql` > > I, personally, like '/var/lib/ignite'. > What do you think? > > > > I doubt that users can attribute work/ directory in their home to Ignite, > > especially when it is used as library by something else. > > I don't think we should fix this case somehow. > If some application-provider uses embedded Ignite, it must do all > configuration stuff inside application. > > Ignite should provide reasonable defaults, that's all. > > > В Пн, 26/08/2019 в 10:33 +0300, Pavel Tupitsyn пишет: > > I was certainly expecting ~/ignite/work too, not just ~/work > > > > On Mon, Aug 26, 2019 at 10:19 AM Dmitriy Pavlov <dpav...@apache.org> > wrote: > > > > > I agree that ~/work is not expected. I was pretty sure it will be > > > ~/ignite/work or ~/.ignite/work > > > > > > Sorry, but ~/work I may use for my day job stuff. I don't expect any > files > > > appear there if I start to play with Apache Ignite for the first time. > > > > > > Since it is a potential usability issue, which is very hard to change > once > > > we release product, > > > > > > I keep the vote open to having an option to cancel it if this > discussion we > > > come to conclusion product should use ~/ignite. > > > > > > пн, 26 авг. 2019 г. в 01:42, Павлухин Иван <vololo...@gmail.com>: > > > > > > > Ilya, > > > > > > > > 2 points: > > > > 1. It is a good point that a directory name "work" in arbitrary place > > > > can cause a lot of confusion. > > > > 2. As far as I got, default directory is not in e.g. /home/username > > > > but in one pointed by "user.dir" system property which is a directory > > > > where a java process started (if property was not overridden). > > > > > > > > 2019-08-26 1:59 GMT+11:00, Ilya Kasnacheev < > ilya.kasnach...@gmail.com>: > > > > > Hello! > > > > > > > > > > I am really worried by the fact that previously we had /tmp/ignite > and > > > > > > in > > > > > it work/, whereas now we're going to write to /home/username/work > > > > > > > > > > I doubt that users can attribute work/ directory in their home to > > > > > > Ignite, > > > > > especially when it is used as library by something else. > > > > > > > > > > Is there a chance we could move this work dir to > /home/username/ignite > > > > > > > > with > > > > > work/ (and possibly logs/) dir in it? WDYT? > > > > > > > > > > We could even auto-create README.TXT in this > /home/username/ignite/ to > > > > > describe that it's Apache Ignite work directory and how to change > it. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > пн, 12 авг. 2019 г. в 19:02, Denis Magda <dma...@apache.org>: > > > > > > > > > > > +1 for the user.dir as a default one. > > > > > > > > > > > > Denis > > > > > > > > > > > > On Monday, August 12, 2019, Dmitriy Pavlov <dpav...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > +1 to user home directory. A number of open source products > create > > > > > > > their > > > > > > > dirs there. For me, it is a kind of expected behavior. > > > > > > > > > > > > > > Ivan mentioned an important point: binary meta & marshaller. We > > > > > > should > > > > > > > update documentation and stop require PDS dir setup, but > require > > > > > > home > > > > > > setup > > > > > > > (for older versions of Ignite, it is relevant anyway). > > > > > > > > > > > > > > пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn < > ptupit...@apache.org>: > > > > > > > > > > > > > > > Hi Ivan, > > > > > > > > > > > > > > > > > fail Ignite node in case neither IGNITE_HOME > > > > > > > > > > > > > > > > nor IgniteConfiguration#igniteWorkDir is set > > > > > > > > I strongly disagree, this is bad usability. > > > > > > > > Ignition.start() should work without any extra configuration > as is > > > > > > > > it > > > > > > > right > > > > > > > > now. > > > > > > > > > > > > > > > > Let's come up with reasonable defaults instead, user dir > sounds > > > > > > good > > > > > > > > to > > > > > > > > > > > > > > me. > > > > > > > > > > > > > > > > On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington < > > > > > > > > stephen.darling...@gridgain.com> wrote: > > > > > > > > > > > > > > > > > Yes, when data is a stake, fail early is the absolutely the > > > > > > right > > > > > > thing > > > > > > > > to > > > > > > > > > do. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Stephen > > > > > > > > > > > > > > > > > > > On 12 Aug 2019, at 16:37, Ivan Rakov < > ivan.glu...@gmail.com> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Anton, > > > > > > > > > > > > > > > > > > > > Actually, the issue is even more unpleasant. > > > > > > > > > > > > > > > > > > > > Official Ignite documentation says that it's possible to > > > > > > > > > > configure > > > > > > > > > > > > > > path > > > > > > > > > where your persistence files will be stored: > > > > > > > > > > > > > > > https://apacheignite.readme.io/docs/distributed-persistent-store > > > > > > > > > > However, even if you have set all path options (storage, > WAL, > > > > > > > > WAL > > > > > > > > > archive), Ignite will still store crucial metadata in > resolved > > > > > > > > work > > > > > > > > > directory (java.io.tmpdir by default). Example is binary > > > > > > metadata > > > > > > > files, > > > > > > > > > absence of which can make your data unavailable. > > > > > > > > > > > > > > > > > > > > I propose to fail Ignite node in case neither > IGNITE_HOME nor > > > > > > > > > > > > > > > > > > IgniteConfiguration#igniteWorkDir is set. It's better to > let > > > > > > user > > > > > > know > > > > > > > > > about missing configuration options during startup than > let OS > > > > > > > > > > > > corrupt > > > > > > > > > storage by cleaning temp dirs. > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > Ivan Rakov > > > > > > > > > > > > > > > > > > > > On 12.08.2019 18:10, Anton Kalashnikov wrote: > > > > > > > > > > > Hello, Igniters. > > > > > > > > > > > > > > > > > > > > > > Currently, in the case, when work directory wasn't set > by > > > > > > user > > > > > > > ignite > > > > > > > > > can resolve it to tmp directory which leads to some > problem - > > > > > > tmp > > > > > > > > directory > > > > > > > > > can be cleared at some unexpected moment by operation > system and > > > > > > > > > > > > > > > > different > > > > > > > > > types of critical data would be lost(ex. binary_meta, > > > > > > persistance > > > > > > > data). > > > > > > > > > > > > > > > > > > > > > > Looks like it is not expected behaviour and maybe it is > > > > > > better > > > > > > > instead > > > > > > > > > of tmp directory use the current working > directory("user.dir")? > > > > > > Or > > > > > > any > > > > > > > > > other idea? > > > > > > > > > > > > > > > > > > > > > > A little more details you can find in the ticket - > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-12057 > > > > > > > > > > > -- > > > > > > > > > > > Best regards, > > > > > > > > > > > Anton Kalashnikov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > >
