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 |
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 > |
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 <[hidden email]> 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 >> |
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 < [hidden email]> 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 <[hidden email]> 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 > >> > > > |
+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 <[hidden email]>: > 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 < > [hidden email]> 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 <[hidden email]> 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 > > >> > > > > > > > |
+1 for the user.dir as a default one.
Denis On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> 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 <[hidden email]>: > > > 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 < > > [hidden email]> 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 <[hidden email]> 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 |
Choosing the smallest of two evils, I'll agree with user.dir.
Being able to run without preset env variables is strong benefit for Ignite as a product. Best Regards, Ivan Rakov On 12.08.2019 19:02, Denis Magda wrote: > +1 for the user.dir as a default one. > > Denis > > On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> 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 <[hidden email]>: >> >>> 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 < >>> [hidden email]> 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 <[hidden email]> 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 >>>>>> >>>> >>>> > |
Both ways are right because there is probability that user home isn't
defined in system. So we should try resolve user dir and fail if it can't be resolved. On Mon, Aug 12, 2019 at 7:04 PM Ivan Rakov <[hidden email]> wrote: > > Choosing the smallest of two evils, I'll agree with user.dir. > Being able to run without preset env variables is strong benefit for > Ignite as a product. > > Best Regards, > Ivan Rakov > > On 12.08.2019 19:02, Denis Magda wrote: > > +1 for the user.dir as a default one. > > > > Denis > > > > On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> 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 <[hidden email]>: > >> > >>> 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 < > >>> [hidden email]> 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 <[hidden email]> 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 > >>>>>> > >>>> > >>>> > > |
In reply to this post by dmagda
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 <[hidden email]>: > +1 for the user.dir as a default one. > > Denis > > On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> 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 <[hidden email]>: > > > > > 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 < > > > [hidden email]> 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 <[hidden email]> > 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 > |
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 <[hidden email]>: > 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 <[hidden email]>: > >> +1 for the user.dir as a default one. >> >> Denis >> >> On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> 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 <[hidden email]>: >> > >> > > 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 < >> > > [hidden email]> 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 <[hidden email]> >> 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 |
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, Павлухин Иван <[hidden email]>: > 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 <[hidden email]>: > > 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 <[hidden email]>: > > > >> +1 for the user.dir as a default one. > >> > >> Denis > >> > >> On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> 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 <[hidden email]>: > >> > > >> > > 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 < > >> > > [hidden email]> 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 <[hidden email]> > >> 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 > |
I was certainly expecting ~/ignite/work too, not just ~/work
On Mon, Aug 26, 2019 at 10:19 AM Dmitriy Pavlov <[hidden email]> 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, Павлухин Иван <[hidden email]>: > > > 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 <[hidden email]>: > > > 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 <[hidden email]>: > > > > > >> +1 for the user.dir as a default one. > > >> > > >> Denis > > >> > > >> On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> > 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 <[hidden email]>: > > >> > > > >> > > 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 < > > >> > > [hidden email]> 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 <[hidden email]> > > >> 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 > > > |
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 <[hidden email]> 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, Павлухин Иван <[hidden email]>: > > > > > 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 <[hidden email]>: > > > > 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 <[hidden email]>: > > > > > > > > > +1 for the user.dir as a default one. > > > > > > > > > > Denis > > > > > > > > > > On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> > > > > 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 <[hidden email]>: > > > > > > > > > > > > > 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 < > > > > > > > [hidden email]> 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 <[hidden email]> > > > > > > > > > > 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 > > > |
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 <[hidden email]>: > 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 <[hidden email]> > 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, Павлухин Иван <[hidden email]>: > > > > > > > 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 < > [hidden email]>: > > > > > 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 <[hidden email]>: > > > > > > > > > > > +1 for the user.dir as a default one. > > > > > > > > > > > > Denis > > > > > > > > > > > > On Monday, August 12, 2019, Dmitriy Pavlov <[hidden email]> > > > > > > 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 < > [hidden email]>: > > > > > > > > > > > > > > > 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 < > > > > > > > > [hidden email]> 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 < > [hidden email]> > > > > > > > > > > > > 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 > > > > > |
Ilya,
> We are talking about development scenario where you have embedded database > in your project and it has to write data somewhere. Why it should differs from production case? I think we should be as close to production setup as we can. > /var/lib/ignite is certainly not writable by user's development projects. mysql, postgresql require some setup in dev env. Why Ignite should differs from it? Please, note, we are talking about scenario when user enable PDS-mode for some cache. For in-memory case, no setup required. > ~/ignite and descendants look like a good compromise Not for me :) > Writing to user.dir/ignite, i.e. current work dir, looks equally good Current work dir in dev env looks good for me. В Пн, 26/08/2019 в 12:06 +0300, Ilya Kasnacheev пишет: > 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, |
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 пн, 26 авг. 2019 г. в 12:17, Nikolay Izhikov <[hidden email]>: > Ilya, > > > We are talking about development scenario where you have embedded > database > > in your project and it has to write data somewhere. > > Why it should differs from production case? > I think we should be as close to production setup as we can. > > > /var/lib/ignite is certainly not writable by user's development projects. > > mysql, postgresql require some setup in dev env. > Why Ignite should differs from it? > > Please, note, we are talking about scenario when user enable PDS-mode for > some cache. > For in-memory case, no setup required. > > > ~/ignite and descendants look like a good compromise > > Not for me :) > > > Writing to user.dir/ignite, i.e. current work dir, looks equally good > > Current work dir in dev env looks good for me. > > > В Пн, 26/08/2019 в 12:06 +0300, Ilya Kasnacheev пишет: > > 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,
> 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, |
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, |
+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, > > |
Hello!
> In development environment one can just run Java from /var/lib/ignite What I actually meant was 'in deployment environment' or even 'in production environment'. Sorry for the confusion. I really dislike the idea of ~/.ignite/work. It is a good default for in-memory runs, but storing gigabytes of sensitive data in a hidden directory is a Bad Idea in my opinion. I now side with user.dir. Regards, -- Ilya Kasnacheev пн, 26 авг. 2019 г. в 13:28, Dmitriy Pavlov <[hidden email]>: > +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, > > > > > |
Free forum by Nabble | Edit this page |