Re: Replacing default work dir from tmp to current dir
Ilya, thanks for the ticket. However, I would advise us to enforce "user.home" as the only one default instead of the proposed fallback mechanism. There is already a lot "if else if else if else" scenarios in Ignite. Let's focus on simplicity and stick to one possible option when it works. This case is an example when one option is doable and preferred. Btw, sounds like 2.7.7? - Denis On Fri, Oct 4, 2019 at 8:34 AM Ilya Kasnacheev wrote: > Hello! > > I have created https://issues.apache.org/jira/browse/IGNITE-12260 > > Regards, > -- > Ilya Kasnacheev > > > пт, 4 окт. 2019 г. в 10:16, Ivan Pavlukhin : > > > Interesting things about those LINQPad/JPad scenarios. Was not aware > > of it. Still some doubts about applicability. It seems to me that JPad > > having work dir in "Program Files" have a lot of problems by itself, > > e.g. a user is not able to run basic file IO snippets with relative > > file paths. > > > > чт, 3 окт. 2019 г. в 23:24, Pavel Tupitsyn : > > > > > > Ilya, fallback is a good idea. > > > Still I'd prefer to have user.home as a default, and fallback to > user.dir > > > when home does not work for some reason. > > > > > > On Thu, Oct 3, 2019 at 11:07 PM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > Hello! > > > > > > > > We can try and fallback to home dir with warning, when file cannot be > > > > created in current dir. > > > > > > > > WDYT? > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > чт, 3 окт. 2019 г. в 20:05, Pavel Tupitsyn : > > > > > > > > > > Cannot tell about NuGet. Maven is typically used during > > development, > > > > > usually there is no Maven in production deployments. > > > > > NuGet and Maven are very similar. Yes, both of them are build-time > > tools, > > > > > production is unrelated. > > > > > For production-ready deployments we can expect users to tweak > Ignite > > to > > > > > their needs, set custom storage dirs, adjust heap sizes and so on. > > > > > > > > > > I'm talking about new users, about "getting started" scenarios - > > > > > it is super important to make Ignite easy to get started with, > > provide > > > > > reasonable defaults for all the configuration properties. > > > > > > > > > > For Ignite.NET, LINQPad is one of those "get started in 2 clicks" > > > > > scenarios. And this scenario got broken as explained above. > > > > > 2.7.5 and earlier used temp dir, which worked. 2.7.6 fails: "Work > > > > directory > > > > > does not exist and cannot be created: C:\Program > > > > > Files\LINQPad5\ignite\work" > > > > > > > > > > For Java there is JPad, which will fail in the same way - when you > > run > > > > code > > > > > from there, `user.dir` points to Program Files. > > > > > > > > > > I expect that there are more use cases like this, and `user.home` > is > > a > > > > > reasonable solution. > > > > > > > > > > On Thu, Oct 3, 2019 at 5:56 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello! > > > > > > > > > > > > I want to point out that I didn't change this location (current > > dir). > > > > It > > > > > > was already implemented when I raised this issue, the only change > > I did > > > > > was > > > > > > to swap current dir/work to current dir/ignite/work to avoid > > confusion > > > > > > whose work dir that is. > > > > > > > > > > > > I also communicated this to you all in ML when I discovered that > > > > current > > > > > > dir is used. > > > > > > > > > > > > I think that current dir is actually *well defined* when > starting a > > > > > > project. A project is expected to be started from the same dir, > > and all > > > > > > "Run..." dialogs usually allow specifying that one. > > > > > > > > > > > > For embedded scenarios, you definitely not want work dir from two > > > > > different > > > > > > Ignite-using tools to interfere. For embedded scenarios, you > should > > > > only > > > > > > expect that current dir is writable. > > > > > > > > > > > > Even after these considerations, it's too late to change that > > because > > > > > > people don't expect this dir to move with every release of > Ignite, > > and > > > > we > > > > > > already did it once. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com > > > > > >: > > > > > > > > > > > > > > > > > > > > > > Seems, we should have different defaults and even > > distributions for > > > > > > > > different usage scenarios. > > > > > > > > > > > > > > > I still do not understand why defaults should be different for > > > > embedded > > > > > > and > > > > > > > "traditional RDBMS-like" installations. Having different > defaults > > > > will > > > > > > > likely confuse users, not make usability easier. Personally, I > > would > > > > > > forbid > > > > > > > to start Ignite if IGNITE_HOME is not set, but this suggestion > > was > >
Re: Replacing default work dir from tmp to current dir
Hello! I have created https://issues.apache.org/jira/browse/IGNITE-12260 Regards, -- Ilya Kasnacheev пт, 4 окт. 2019 г. в 10:16, Ivan Pavlukhin : > Interesting things about those LINQPad/JPad scenarios. Was not aware > of it. Still some doubts about applicability. It seems to me that JPad > having work dir in "Program Files" have a lot of problems by itself, > e.g. a user is not able to run basic file IO snippets with relative > file paths. > > чт, 3 окт. 2019 г. в 23:24, Pavel Tupitsyn : > > > > Ilya, fallback is a good idea. > > Still I'd prefer to have user.home as a default, and fallback to user.dir > > when home does not work for some reason. > > > > On Thu, Oct 3, 2019 at 11:07 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > wrote: > > > > > Hello! > > > > > > We can try and fallback to home dir with warning, when file cannot be > > > created in current dir. > > > > > > WDYT? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 3 окт. 2019 г. в 20:05, Pavel Tupitsyn : > > > > > > > > Cannot tell about NuGet. Maven is typically used during > development, > > > > usually there is no Maven in production deployments. > > > > NuGet and Maven are very similar. Yes, both of them are build-time > tools, > > > > production is unrelated. > > > > For production-ready deployments we can expect users to tweak Ignite > to > > > > their needs, set custom storage dirs, adjust heap sizes and so on. > > > > > > > > I'm talking about new users, about "getting started" scenarios - > > > > it is super important to make Ignite easy to get started with, > provide > > > > reasonable defaults for all the configuration properties. > > > > > > > > For Ignite.NET, LINQPad is one of those "get started in 2 clicks" > > > > scenarios. And this scenario got broken as explained above. > > > > 2.7.5 and earlier used temp dir, which worked. 2.7.6 fails: "Work > > > directory > > > > does not exist and cannot be created: C:\Program > > > > Files\LINQPad5\ignite\work" > > > > > > > > For Java there is JPad, which will fail in the same way - when you > run > > > code > > > > from there, `user.dir` points to Program Files. > > > > > > > > I expect that there are more use cases like this, and `user.home` is > a > > > > reasonable solution. > > > > > > > > On Thu, Oct 3, 2019 at 5:56 PM Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > I want to point out that I didn't change this location (current > dir). > > > It > > > > > was already implemented when I raised this issue, the only change > I did > > > > was > > > > > to swap current dir/work to current dir/ignite/work to avoid > confusion > > > > > whose work dir that is. > > > > > > > > > > I also communicated this to you all in ML when I discovered that > > > current > > > > > dir is used. > > > > > > > > > > I think that current dir is actually *well defined* when starting a > > > > > project. A project is expected to be started from the same dir, > and all > > > > > "Run..." dialogs usually allow specifying that one. > > > > > > > > > > For embedded scenarios, you definitely not want work dir from two > > > > different > > > > > Ignite-using tools to interfere. For embedded scenarios, you should > > > only > > > > > expect that current dir is writable. > > > > > > > > > > Even after these considerations, it's too late to change that > because > > > > > people don't expect this dir to move with every release of Ignite, > and > > > we > > > > > already did it once. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > > >: > > > > > > > > > > > > > > > > > > > Seems, we should have different defaults and even > distributions for > > > > > > > different usage scenarios. > > > > > > > > > > > > > I still do not understand why defaults should be different for > > > embedded > > > > > and > > > > > > "traditional RDBMS-like" installations. Having different defaults > > > will > > > > > > likely confuse users, not make usability easier. Personally, I > would > > > > > forbid > > > > > > to start Ignite if IGNITE_HOME is not set, but this suggestion > was > > > not > > > > > > accepted by the community. > > > > > > > > > > > > As far as I know, both rocksdb and SQLite is local only > libraries and > > > > > don't > > > > > > > have any distrubted features. > > > > > > > > > > > > See no difference here. Imagine a user starts only one Ignite > node > > > for > > > > > > development or just to play (which, I believe, happes quite a > lot) - > > > > same > > > > > > as with local databases. BTW, it is impossible to start SQLite > > > without > > > > > > database path, so a user either provides a full path, or a > relative > > > > path > > > > > > from the current directory - which is an explicit action from a > user. > > > > > > > > > > > > > > > > > > > I agree with you. >
Re: Replacing default work dir from tmp to current dir
Interesting things about those LINQPad/JPad scenarios. Was not aware of it. Still some doubts about applicability. It seems to me that JPad having work dir in "Program Files" have a lot of problems by itself, e.g. a user is not able to run basic file IO snippets with relative file paths. чт, 3 окт. 2019 г. в 23:24, Pavel Tupitsyn : > > Ilya, fallback is a good idea. > Still I'd prefer to have user.home as a default, and fallback to user.dir > when home does not work for some reason. > > On Thu, Oct 3, 2019 at 11:07 PM Ilya Kasnacheev > wrote: > > > Hello! > > > > We can try and fallback to home dir with warning, when file cannot be > > created in current dir. > > > > WDYT? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 3 окт. 2019 г. в 20:05, Pavel Tupitsyn : > > > > > > Cannot tell about NuGet. Maven is typically used during development, > > > usually there is no Maven in production deployments. > > > NuGet and Maven are very similar. Yes, both of them are build-time tools, > > > production is unrelated. > > > For production-ready deployments we can expect users to tweak Ignite to > > > their needs, set custom storage dirs, adjust heap sizes and so on. > > > > > > I'm talking about new users, about "getting started" scenarios - > > > it is super important to make Ignite easy to get started with, provide > > > reasonable defaults for all the configuration properties. > > > > > > For Ignite.NET, LINQPad is one of those "get started in 2 clicks" > > > scenarios. And this scenario got broken as explained above. > > > 2.7.5 and earlier used temp dir, which worked. 2.7.6 fails: "Work > > directory > > > does not exist and cannot be created: C:\Program > > > Files\LINQPad5\ignite\work" > > > > > > For Java there is JPad, which will fail in the same way - when you run > > code > > > from there, `user.dir` points to Program Files. > > > > > > I expect that there are more use cases like this, and `user.home` is a > > > reasonable solution. > > > > > > On Thu, Oct 3, 2019 at 5:56 PM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > Hello! > > > > > > > > I want to point out that I didn't change this location (current dir). > > It > > > > was already implemented when I raised this issue, the only change I did > > > was > > > > to swap current dir/work to current dir/ignite/work to avoid confusion > > > > whose work dir that is. > > > > > > > > I also communicated this to you all in ML when I discovered that > > current > > > > dir is used. > > > > > > > > I think that current dir is actually *well defined* when starting a > > > > project. A project is expected to be started from the same dir, and all > > > > "Run..." dialogs usually allow specifying that one. > > > > > > > > For embedded scenarios, you definitely not want work dir from two > > > different > > > > Ignite-using tools to interfere. For embedded scenarios, you should > > only > > > > expect that current dir is writable. > > > > > > > > Even after these considerations, it's too late to change that because > > > > people don't expect this dir to move with every release of Ignite, and > > we > > > > already did it once. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk < > > alexey.goncha...@gmail.com > > > >: > > > > > > > > > > > > > > > > Seems, we should have different defaults and even distributions for > > > > > > different usage scenarios. > > > > > > > > > > > I still do not understand why defaults should be different for > > embedded > > > > and > > > > > "traditional RDBMS-like" installations. Having different defaults > > will > > > > > likely confuse users, not make usability easier. Personally, I would > > > > forbid > > > > > to start Ignite if IGNITE_HOME is not set, but this suggestion was > > not > > > > > accepted by the community. > > > > > > > > > > As far as I know, both rocksdb and SQLite is local only libraries and > > > > don't > > > > > > have any distrubted features. > > > > > > > > > > See no difference here. Imagine a user starts only one Ignite node > > for > > > > > development or just to play (which, I believe, happes quite a lot) - > > > same > > > > > as with local databases. BTW, it is impossible to start SQLite > > without > > > > > database path, so a user either provides a full path, or a relative > > > path > > > > > from the current directory - which is an explicit action from a user. > > > > > > > > > > > > > > > > I agree with you. > > > > > > How it happens, that after wide discussion we implemented, reviewed > > > and > > > > > > merged wrong defaults? > > > > > > > > > > > > As I know, we have explicit release only to change this default. > > > > > > > > > > > > This release is broken, isn't it? > > > > > > > > > > > I think this is just a miscommunication. Ilya made a fix which was > > > > exactly > > > > > what he meant it to be. As for the release - it may have worse > > > usability, > > > >
Re: Replacing default work dir from tmp to current dir
Ilya, fallback is a good idea. Still I'd prefer to have user.home as a default, and fallback to user.dir when home does not work for some reason. On Thu, Oct 3, 2019 at 11:07 PM Ilya Kasnacheev wrote: > Hello! > > We can try and fallback to home dir with warning, when file cannot be > created in current dir. > > WDYT? > > Regards, > -- > Ilya Kasnacheev > > > чт, 3 окт. 2019 г. в 20:05, Pavel Tupitsyn : > > > > Cannot tell about NuGet. Maven is typically used during development, > > usually there is no Maven in production deployments. > > NuGet and Maven are very similar. Yes, both of them are build-time tools, > > production is unrelated. > > For production-ready deployments we can expect users to tweak Ignite to > > their needs, set custom storage dirs, adjust heap sizes and so on. > > > > I'm talking about new users, about "getting started" scenarios - > > it is super important to make Ignite easy to get started with, provide > > reasonable defaults for all the configuration properties. > > > > For Ignite.NET, LINQPad is one of those "get started in 2 clicks" > > scenarios. And this scenario got broken as explained above. > > 2.7.5 and earlier used temp dir, which worked. 2.7.6 fails: "Work > directory > > does not exist and cannot be created: C:\Program > > Files\LINQPad5\ignite\work" > > > > For Java there is JPad, which will fail in the same way - when you run > code > > from there, `user.dir` points to Program Files. > > > > I expect that there are more use cases like this, and `user.home` is a > > reasonable solution. > > > > On Thu, Oct 3, 2019 at 5:56 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > wrote: > > > > > Hello! > > > > > > I want to point out that I didn't change this location (current dir). > It > > > was already implemented when I raised this issue, the only change I did > > was > > > to swap current dir/work to current dir/ignite/work to avoid confusion > > > whose work dir that is. > > > > > > I also communicated this to you all in ML when I discovered that > current > > > dir is used. > > > > > > I think that current dir is actually *well defined* when starting a > > > project. A project is expected to be started from the same dir, and all > > > "Run..." dialogs usually allow specifying that one. > > > > > > For embedded scenarios, you definitely not want work dir from two > > different > > > Ignite-using tools to interfere. For embedded scenarios, you should > only > > > expect that current dir is writable. > > > > > > Even after these considerations, it's too late to change that because > > > people don't expect this dir to move with every release of Ignite, and > we > > > already did it once. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > > > > > > > > > Seems, we should have different defaults and even distributions for > > > > > different usage scenarios. > > > > > > > > > I still do not understand why defaults should be different for > embedded > > > and > > > > "traditional RDBMS-like" installations. Having different defaults > will > > > > likely confuse users, not make usability easier. Personally, I would > > > forbid > > > > to start Ignite if IGNITE_HOME is not set, but this suggestion was > not > > > > accepted by the community. > > > > > > > > As far as I know, both rocksdb and SQLite is local only libraries and > > > don't > > > > > have any distrubted features. > > > > > > > > See no difference here. Imagine a user starts only one Ignite node > for > > > > development or just to play (which, I believe, happes quite a lot) - > > same > > > > as with local databases. BTW, it is impossible to start SQLite > without > > > > database path, so a user either provides a full path, or a relative > > path > > > > from the current directory - which is an explicit action from a user. > > > > > > > > > > > > > I agree with you. > > > > > How it happens, that after wide discussion we implemented, reviewed > > and > > > > > merged wrong defaults? > > > > > > > > > > As I know, we have explicit release only to change this default. > > > > > > > > > > This release is broken, isn't it? > > > > > > > > > I think this is just a miscommunication. Ilya made a fix which was > > > exactly > > > > what he meant it to be. As for the release - it may have worse > > usability, > > > > but not more 'broken' as the previous one with the temp directory. At > > > least > > > > the data will not be physically removed after the machine restart. > > > > > > > > > >
Re: Replacing default work dir from tmp to current dir
Hello! We can try and fallback to home dir with warning, when file cannot be created in current dir. WDYT? Regards, -- Ilya Kasnacheev чт, 3 окт. 2019 г. в 20:05, Pavel Tupitsyn : > > Cannot tell about NuGet. Maven is typically used during development, > usually there is no Maven in production deployments. > NuGet and Maven are very similar. Yes, both of them are build-time tools, > production is unrelated. > For production-ready deployments we can expect users to tweak Ignite to > their needs, set custom storage dirs, adjust heap sizes and so on. > > I'm talking about new users, about "getting started" scenarios - > it is super important to make Ignite easy to get started with, provide > reasonable defaults for all the configuration properties. > > For Ignite.NET, LINQPad is one of those "get started in 2 clicks" > scenarios. And this scenario got broken as explained above. > 2.7.5 and earlier used temp dir, which worked. 2.7.6 fails: "Work directory > does not exist and cannot be created: C:\Program > Files\LINQPad5\ignite\work" > > For Java there is JPad, which will fail in the same way - when you run code > from there, `user.dir` points to Program Files. > > I expect that there are more use cases like this, and `user.home` is a > reasonable solution. > > On Thu, Oct 3, 2019 at 5:56 PM Ilya Kasnacheev > wrote: > > > Hello! > > > > I want to point out that I didn't change this location (current dir). It > > was already implemented when I raised this issue, the only change I did > was > > to swap current dir/work to current dir/ignite/work to avoid confusion > > whose work dir that is. > > > > I also communicated this to you all in ML when I discovered that current > > dir is used. > > > > I think that current dir is actually *well defined* when starting a > > project. A project is expected to be started from the same dir, and all > > "Run..." dialogs usually allow specifying that one. > > > > For embedded scenarios, you definitely not want work dir from two > different > > Ignite-using tools to interfere. For embedded scenarios, you should only > > expect that current dir is writable. > > > > Even after these considerations, it's too late to change that because > > people don't expect this dir to move with every release of Ignite, and we > > already did it once. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk >: > > > > > > > > > > Seems, we should have different defaults and even distributions for > > > > different usage scenarios. > > > > > > > I still do not understand why defaults should be different for embedded > > and > > > "traditional RDBMS-like" installations. Having different defaults will > > > likely confuse users, not make usability easier. Personally, I would > > forbid > > > to start Ignite if IGNITE_HOME is not set, but this suggestion was not > > > accepted by the community. > > > > > > As far as I know, both rocksdb and SQLite is local only libraries and > > don't > > > > have any distrubted features. > > > > > > See no difference here. Imagine a user starts only one Ignite node for > > > development or just to play (which, I believe, happes quite a lot) - > same > > > as with local databases. BTW, it is impossible to start SQLite without > > > database path, so a user either provides a full path, or a relative > path > > > from the current directory - which is an explicit action from a user. > > > > > > > > > > I agree with you. > > > > How it happens, that after wide discussion we implemented, reviewed > and > > > > merged wrong defaults? > > > > > > > > As I know, we have explicit release only to change this default. > > > > > > > > This release is broken, isn't it? > > > > > > > I think this is just a miscommunication. Ilya made a fix which was > > exactly > > > what he meant it to be. As for the release - it may have worse > usability, > > > but not more 'broken' as the previous one with the temp directory. At > > least > > > the data will not be physically removed after the machine restart. > > > > > >
Re: Replacing default work dir from tmp to current dir
> Cannot tell about NuGet. Maven is typically used during development, usually there is no Maven in production deployments. NuGet and Maven are very similar. Yes, both of them are build-time tools, production is unrelated. For production-ready deployments we can expect users to tweak Ignite to their needs, set custom storage dirs, adjust heap sizes and so on. I'm talking about new users, about "getting started" scenarios - it is super important to make Ignite easy to get started with, provide reasonable defaults for all the configuration properties. For Ignite.NET, LINQPad is one of those "get started in 2 clicks" scenarios. And this scenario got broken as explained above. 2.7.5 and earlier used temp dir, which worked. 2.7.6 fails: "Work directory does not exist and cannot be created: C:\Program Files\LINQPad5\ignite\work" For Java there is JPad, which will fail in the same way - when you run code from there, `user.dir` points to Program Files. I expect that there are more use cases like this, and `user.home` is a reasonable solution. On Thu, Oct 3, 2019 at 5:56 PM Ilya Kasnacheev wrote: > Hello! > > I want to point out that I didn't change this location (current dir). It > was already implemented when I raised this issue, the only change I did was > to swap current dir/work to current dir/ignite/work to avoid confusion > whose work dir that is. > > I also communicated this to you all in ML when I discovered that current > dir is used. > > I think that current dir is actually *well defined* when starting a > project. A project is expected to be started from the same dir, and all > "Run..." dialogs usually allow specifying that one. > > For embedded scenarios, you definitely not want work dir from two different > Ignite-using tools to interfere. For embedded scenarios, you should only > expect that current dir is writable. > > Even after these considerations, it's too late to change that because > people don't expect this dir to move with every release of Ignite, and we > already did it once. > > Regards, > -- > Ilya Kasnacheev > > > чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk : > > > > > > > Seems, we should have different defaults and even distributions for > > > different usage scenarios. > > > > > I still do not understand why defaults should be different for embedded > and > > "traditional RDBMS-like" installations. Having different defaults will > > likely confuse users, not make usability easier. Personally, I would > forbid > > to start Ignite if IGNITE_HOME is not set, but this suggestion was not > > accepted by the community. > > > > As far as I know, both rocksdb and SQLite is local only libraries and > don't > > > have any distrubted features. > > > > See no difference here. Imagine a user starts only one Ignite node for > > development or just to play (which, I believe, happes quite a lot) - same > > as with local databases. BTW, it is impossible to start SQLite without > > database path, so a user either provides a full path, or a relative path > > from the current directory - which is an explicit action from a user. > > > > > > > I agree with you. > > > How it happens, that after wide discussion we implemented, reviewed and > > > merged wrong defaults? > > > > > > As I know, we have explicit release only to change this default. > > > > > > This release is broken, isn't it? > > > > > I think this is just a miscommunication. Ilya made a fix which was > exactly > > what he meant it to be. As for the release - it may have worse usability, > > but not more 'broken' as the previous one with the temp directory. At > least > > the data will not be physically removed after the machine restart. > > >
Re: Replacing default work dir from tmp to current dir
Hello! I want to point out that I didn't change this location (current dir). It was already implemented when I raised this issue, the only change I did was to swap current dir/work to current dir/ignite/work to avoid confusion whose work dir that is. I also communicated this to you all in ML when I discovered that current dir is used. I think that current dir is actually *well defined* when starting a project. A project is expected to be started from the same dir, and all "Run..." dialogs usually allow specifying that one. For embedded scenarios, you definitely not want work dir from two different Ignite-using tools to interfere. For embedded scenarios, you should only expect that current dir is writable. Even after these considerations, it's too late to change that because people don't expect this dir to move with every release of Ignite, and we already did it once. Regards, -- Ilya Kasnacheev чт, 3 окт. 2019 г. в 17:34, Alexey Goncharuk : > > > > Seems, we should have different defaults and even distributions for > > different usage scenarios. > > > I still do not understand why defaults should be different for embedded and > "traditional RDBMS-like" installations. Having different defaults will > likely confuse users, not make usability easier. Personally, I would forbid > to start Ignite if IGNITE_HOME is not set, but this suggestion was not > accepted by the community. > > As far as I know, both rocksdb and SQLite is local only libraries and don't > > have any distrubted features. > > See no difference here. Imagine a user starts only one Ignite node for > development or just to play (which, I believe, happes quite a lot) - same > as with local databases. BTW, it is impossible to start SQLite without > database path, so a user either provides a full path, or a relative path > from the current directory - which is an explicit action from a user. > > > > I agree with you. > > How it happens, that after wide discussion we implemented, reviewed and > > merged wrong defaults? > > > > As I know, we have explicit release only to change this default. > > > > This release is broken, isn't it? > > > I think this is just a miscommunication. Ilya made a fix which was exactly > what he meant it to be. As for the release - it may have worse usability, > but not more 'broken' as the previous one with the temp directory. At least > the data will not be physically removed after the machine restart. >
Re: Replacing default work dir from tmp to current dir
> > Seems, we should have different defaults and even distributions for > different usage scenarios. > I still do not understand why defaults should be different for embedded and "traditional RDBMS-like" installations. Having different defaults will likely confuse users, not make usability easier. Personally, I would forbid to start Ignite if IGNITE_HOME is not set, but this suggestion was not accepted by the community. As far as I know, both rocksdb and SQLite is local only libraries and don't > have any distrubted features. See no difference here. Imagine a user starts only one Ignite node for development or just to play (which, I believe, happes quite a lot) - same as with local databases. BTW, it is impossible to start SQLite without database path, so a user either provides a full path, or a relative path from the current directory - which is an explicit action from a user. > I agree with you. > How it happens, that after wide discussion we implemented, reviewed and > merged wrong defaults? > > As I know, we have explicit release only to change this default. > > This release is broken, isn't it? > I think this is just a miscommunication. Ilya made a fix which was exactly what he meant it to be. As for the release - it may have worse usability, but not more 'broken' as the previous one with the temp directory. At least the data will not be physically removed after the machine restart.
Re: Replacing default work dir from tmp to current dir
Pavel, > Ivan, which vendors place files into current work dir, can you please give an > example? Cockroachdb stores files relative to current work dir (yes, "cd" sensitive). As I understood aforementioned SQLite do the same [1]. > In this case users won't even be able to use Maven or NuGet, let's not > consider those rare scenarios. Cannot tell about NuGet. Maven is typically used during development, usually there is no Maven in production deployments. Folks, I believe we should definitely wait a reply from Ilya, as the fix was not done blindly. [1] https://www.sqlite.org/c3ref/data_directory.html чт, 3 окт. 2019 г. в 14:19, Nikolay Izhikov : > > Alexey. > > > Ignite is widely used in embedded scenarios; the ability to process data > > in-process locally is very powerful and I see no reason why we should > > remove it > > I don't propose to remove something. > I wrote about "same distribution". > > Seems, we should have different defaults and even distributions for different > usage scenarios. > > > As an example, > > both SQLite, and rocksdb are distributed as a library, so I see no issues > > in Ignite server side being a library. > > As far as I know, both rocksdb and SQLite is local only libraries and don't > have any distrubted features. > > > >"current directory" as persistence directory is not consistent. > > I agree with you. > How it happens, that after wide discussion we implemented, reviewed and > merged wrong defaults? > > As I know, we have explicit release only to change this default. > > This release is broken, isn't it? > > В Чт, 03/10/2019 в 14:03 +0300, Alexey Goncharuk пишет: > > Nikolay, > > > > Ignite is widely used in embedded scenarios; the ability to process data > > in-process locally is very powerful and I see no reason why we should > > remove it. I absolutely agree with Pavel T. on the subject. As an example, > > both SQLite, and rocksdb are distributed as a library, so I see no issues > > in Ignite server side being a library. > > > > As long as Ignite is available as a maven library, we should provide a > > consistent node behavior; "current directory" as persistence directory is > > not consistent. > > > > чт, 3 окт. 2019 г. в 13:52, Nikolay Izhikov : > > > > > Pavel. > > > > > > > As a user, why would I want to define a system-wide property just to use > > > > some library? > > > > > > Why do you think Ignite is a library? > > > May be the root of usability issues in using same distribution for a > > > library and server side dbms? > > > > > > > > > В Чт, 03/10/2019 в 13:40 +0300, Pavel Tupitsyn пишет: > > > > Ivan, which vendors place files into current work dir, can you please > > > > > > give > > > > an example? > > > > > > > > > Generally IGNITE_HOME should be defined > > > > > > > > This is an inconvenience for the users, bad usability. > > > > As a user, why would I want to define a system-wide property just to use > > > > some library? > > > > > > > > > As for .NET. Should not we define IGNITE_HOME for it? > > > > > > > > No, for the reasons stated above. > > > > > > > > I'd like everyone to pay more attention to Maven/NuGet distribution > > > > scenario. Forget about zip archive for a while. > > > > As a user, I add a dependency to Ignite package and call > > > > > > Ignition.start(). > > > > That's all, it should work right away, no env vars, no additional > > > > configuration. > > > > And current work dir should not matter, because different tools, IDEs > > > > and > > > > workflows dictate different work directories. > > > > > > > > > user.home can be not writable as well > > > > > > > > In this case users won't even be able to use Maven or NuGet, let's not > > > > consider those rare scenarios. > > > > > > > > > > > > To summarize: home directory is the way to go as a default location. > > > > > > > > On Thu, Oct 3, 2019 at 12:14 PM Ivan Pavlukhin > > > > > > wrote: > > > > > > > > > As for .NET. Should not we define IGNITE_HOME for it? > > > > > > > > > > чт, 3 окт. 2019 г. в 12:13, Ivan Pavlukhin : > > > > > > > > > > > > Folks, > > > > > > > > > > > > I am with Ilya here. I remind that we are talking not about general > > > > > > case for Ignite usage. Generally IGNITE_HOME should be defined. > > > > > > Otherwise we fallback to a default, and user.dir usually points to a > > > > > > directory where java launcher command was called (work dir). > > > > > > > > > > > > user.home seems to cause more surprises to me: > > > > > > * user.home can be undefined for JVM; > > > > > > * user.home can be not writable as well (e.g. some special service > > > > > > user). > > > > > > > > > > > > And as far as know other vendors usually place files required for an > > > > > > application in current work dir. > > > > > > > > > > > > чт, 3 окт. 2019 г. в 01:45, Denis Magda : > > > > > > > > > > > > > > I was always expecting this to be a user *home* directory that can > > > > > > be > > > > > > > resolved in any operating system and will work for any language
Re: Replacing default work dir from tmp to current dir
Alexey. > Ignite is widely used in embedded scenarios; the ability to process data > in-process locally is very powerful and I see no reason why we should > remove it I don't propose to remove something. I wrote about "same distribution". Seems, we should have different defaults and even distributions for different usage scenarios. > As an example, > both SQLite, and rocksdb are distributed as a library, so I see no issues > in Ignite server side being a library. As far as I know, both rocksdb and SQLite is local only libraries and don't have any distrubted features. >"current directory" as persistence directory is not consistent. I agree with you. How it happens, that after wide discussion we implemented, reviewed and merged wrong defaults? As I know, we have explicit release only to change this default. This release is broken, isn't it? В Чт, 03/10/2019 в 14:03 +0300, Alexey Goncharuk пишет: > Nikolay, > > Ignite is widely used in embedded scenarios; the ability to process data > in-process locally is very powerful and I see no reason why we should > remove it. I absolutely agree with Pavel T. on the subject. As an example, > both SQLite, and rocksdb are distributed as a library, so I see no issues > in Ignite server side being a library. > > As long as Ignite is available as a maven library, we should provide a > consistent node behavior; "current directory" as persistence directory is > not consistent. > > чт, 3 окт. 2019 г. в 13:52, Nikolay Izhikov : > > > Pavel. > > > > > As a user, why would I want to define a system-wide property just to use > > > some library? > > > > Why do you think Ignite is a library? > > May be the root of usability issues in using same distribution for a > > library and server side dbms? > > > > > > В Чт, 03/10/2019 в 13:40 +0300, Pavel Tupitsyn пишет: > > > Ivan, which vendors place files into current work dir, can you please > > > > give > > > an example? > > > > > > > Generally IGNITE_HOME should be defined > > > > > > This is an inconvenience for the users, bad usability. > > > As a user, why would I want to define a system-wide property just to use > > > some library? > > > > > > > As for .NET. Should not we define IGNITE_HOME for it? > > > > > > No, for the reasons stated above. > > > > > > I'd like everyone to pay more attention to Maven/NuGet distribution > > > scenario. Forget about zip archive for a while. > > > As a user, I add a dependency to Ignite package and call > > > > Ignition.start(). > > > That's all, it should work right away, no env vars, no additional > > > configuration. > > > And current work dir should not matter, because different tools, IDEs and > > > workflows dictate different work directories. > > > > > > > user.home can be not writable as well > > > > > > In this case users won't even be able to use Maven or NuGet, let's not > > > consider those rare scenarios. > > > > > > > > > To summarize: home directory is the way to go as a default location. > > > > > > On Thu, Oct 3, 2019 at 12:14 PM Ivan Pavlukhin > > > > wrote: > > > > > > > As for .NET. Should not we define IGNITE_HOME for it? > > > > > > > > чт, 3 окт. 2019 г. в 12:13, Ivan Pavlukhin : > > > > > > > > > > Folks, > > > > > > > > > > I am with Ilya here. I remind that we are talking not about general > > > > > case for Ignite usage. Generally IGNITE_HOME should be defined. > > > > > Otherwise we fallback to a default, and user.dir usually points to a > > > > > directory where java launcher command was called (work dir). > > > > > > > > > > user.home seems to cause more surprises to me: > > > > > * user.home can be undefined for JVM; > > > > > * user.home can be not writable as well (e.g. some special service > > > > user). > > > > > > > > > > And as far as know other vendors usually place files required for an > > > > > application in current work dir. > > > > > > > > > > чт, 3 окт. 2019 г. в 01:45, Denis Magda : > > > > > > > > > > > > I was always expecting this to be a user *home* directory that can > > > > be > > > > > > resolved in any operating system and will work for any language > > > > > > > > supported > > > > > > by Ignite. So, I'm with Pavel here. > > > > > > > > > > > > Alex G, what's your thinking? Sounds like we need to change this > > > > one > > > > > > > > more > > > > > > time. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Wed, Oct 2, 2019 at 12:17 PM Pavel Tupitsyn < > > > > ptupit...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > Everyone above agreed to `~/ignite/work`, then somehow we jumped > > > > to > > > > > > > `user.dir/ignite/work`. > > > > > > > To me `user.dir` looked like synonym for ~, but turns out this is > > > > > > > > not true. > > > > > > > I think others may be confused in the same way. > > > > > > > > > > > > > > Denis Magda, Alexey Goncharuk, and others - please confirm that > > > > you > > > > > > > understand that `user.dir` means
Re: Replacing default work dir from tmp to current dir
Pavel. > As a user, why would I want to define a system-wide property just to use > some library? Why do you think Ignite is a library? May be the root of usability issues in using same distribution for a library and server side dbms? В Чт, 03/10/2019 в 13:40 +0300, Pavel Tupitsyn пишет: > Ivan, which vendors place files into current work dir, can you please give > an example? > > > Generally IGNITE_HOME should be defined > > This is an inconvenience for the users, bad usability. > As a user, why would I want to define a system-wide property just to use > some library? > > > As for .NET. Should not we define IGNITE_HOME for it? > > No, for the reasons stated above. > > I'd like everyone to pay more attention to Maven/NuGet distribution > scenario. Forget about zip archive for a while. > As a user, I add a dependency to Ignite package and call Ignition.start(). > That's all, it should work right away, no env vars, no additional > configuration. > And current work dir should not matter, because different tools, IDEs and > workflows dictate different work directories. > > > user.home can be not writable as well > > In this case users won't even be able to use Maven or NuGet, let's not > consider those rare scenarios. > > > To summarize: home directory is the way to go as a default location. > > On Thu, Oct 3, 2019 at 12:14 PM Ivan Pavlukhin wrote: > > > As for .NET. Should not we define IGNITE_HOME for it? > > > > чт, 3 окт. 2019 г. в 12:13, Ivan Pavlukhin : > > > > > > Folks, > > > > > > I am with Ilya here. I remind that we are talking not about general > > > case for Ignite usage. Generally IGNITE_HOME should be defined. > > > Otherwise we fallback to a default, and user.dir usually points to a > > > directory where java launcher command was called (work dir). > > > > > > user.home seems to cause more surprises to me: > > > * user.home can be undefined for JVM; > > > * user.home can be not writable as well (e.g. some special service user). > > > > > > And as far as know other vendors usually place files required for an > > > application in current work dir. > > > > > > чт, 3 окт. 2019 г. в 01:45, Denis Magda : > > > > > > > > I was always expecting this to be a user *home* directory that can be > > > > resolved in any operating system and will work for any language > > > > supported > > > > by Ignite. So, I'm with Pavel here. > > > > > > > > Alex G, what's your thinking? Sounds like we need to change this one > > > > more > > > > time. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Wed, Oct 2, 2019 at 12:17 PM Pavel Tupitsyn > > > > wrote: > > > > > > > > > Everyone above agreed to `~/ignite/work`, then somehow we jumped to > > > > > `user.dir/ignite/work`. > > > > > To me `user.dir` looked like synonym for ~, but turns out this is > > > > not true. > > > > > I think others may be confused in the same way. > > > > > > > > > > Denis Magda, Alexey Goncharuk, and others - please confirm that you > > > > > understand that `user.dir` means current directory, not user home > > > > > directory. > > > > > > > > > > In my opinion, this is very broken. Current work dir can be literally > > > > > anything, e.g.: > > > > > `cd / && ~/my-ignite-app/run.sh` will cause an attempt to create > > > > ignite dir > > > > > in system root, and so on. > > > > > > > > > > > > > > > > > > > > On Wed, Oct 2, 2019 at 9:46 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello! > > > > > > > > > > > > I think this is a sensible default and it was certainly not chosen > > > > by > > > > > > mistake. It was intentional expectation that your project is > > > > started from > > > > > > project root and data is located under it. > > > > > > > > > > > > If this breaks .Net, I am deeply sorry. > > > > > > However, I think we should change .net to provide non-default > > > > workdir > > > > > > location when none is specified. > > > > > > > > > > > > Can you please clarify scenarios that are broken now? > > > > > > > > > > > > Regards, > > > > > > > > > > > > ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > Looks like we made a mistake while implementing IGNITE-12057: > > > > > > > `user.dir` is NOT user home directory, it is where JVM has been > > > > started > > > > > > > from, which is rather arbitrary. > > > > > > > (Among other things this breaks Ignite.NET usage from tools like > > > > > > > > > > LINQPad, > > > > > > > because `user.dir` ends up pointing to Program Files, which is > > > > not > > > > > > > writable without elevation) > > > > > > > > > > > > > > We should use `user.home` system property instead, see > > > > > > > > > > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > > > > > > > > > > > > > Thoughts, objections? > > > > > > > > > > > > > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev < > > > > > > > > > > > >
Re: Replacing default work dir from tmp to current dir
Ivan, which vendors place files into current work dir, can you please give an example? > Generally IGNITE_HOME should be defined This is an inconvenience for the users, bad usability. As a user, why would I want to define a system-wide property just to use some library? > As for .NET. Should not we define IGNITE_HOME for it? No, for the reasons stated above. I'd like everyone to pay more attention to Maven/NuGet distribution scenario. Forget about zip archive for a while. As a user, I add a dependency to Ignite package and call Ignition.start(). That's all, it should work right away, no env vars, no additional configuration. And current work dir should not matter, because different tools, IDEs and workflows dictate different work directories. > user.home can be not writable as well In this case users won't even be able to use Maven or NuGet, let's not consider those rare scenarios. To summarize: home directory is the way to go as a default location. On Thu, Oct 3, 2019 at 12:14 PM Ivan Pavlukhin wrote: > As for .NET. Should not we define IGNITE_HOME for it? > > чт, 3 окт. 2019 г. в 12:13, Ivan Pavlukhin : > > > > Folks, > > > > I am with Ilya here. I remind that we are talking not about general > > case for Ignite usage. Generally IGNITE_HOME should be defined. > > Otherwise we fallback to a default, and user.dir usually points to a > > directory where java launcher command was called (work dir). > > > > user.home seems to cause more surprises to me: > > * user.home can be undefined for JVM; > > * user.home can be not writable as well (e.g. some special service user). > > > > And as far as know other vendors usually place files required for an > > application in current work dir. > > > > чт, 3 окт. 2019 г. в 01:45, Denis Magda : > > > > > > I was always expecting this to be a user *home* directory that can be > > > resolved in any operating system and will work for any language > supported > > > by Ignite. So, I'm with Pavel here. > > > > > > Alex G, what's your thinking? Sounds like we need to change this one > more > > > time. > > > > > > - > > > Denis > > > > > > > > > On Wed, Oct 2, 2019 at 12:17 PM Pavel Tupitsyn > wrote: > > > > > > > Everyone above agreed to `~/ignite/work`, then somehow we jumped to > > > > `user.dir/ignite/work`. > > > > To me `user.dir` looked like synonym for ~, but turns out this is > not true. > > > > I think others may be confused in the same way. > > > > > > > > Denis Magda, Alexey Goncharuk, and others - please confirm that you > > > > understand that `user.dir` means current directory, not user home > > > > directory. > > > > > > > > In my opinion, this is very broken. Current work dir can be literally > > > > anything, e.g.: > > > > `cd / && ~/my-ignite-app/run.sh` will cause an attempt to create > ignite dir > > > > in system root, and so on. > > > > > > > > > > > > > > > > On Wed, Oct 2, 2019 at 9:46 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > I think this is a sensible default and it was certainly not chosen > by > > > > > mistake. It was intentional expectation that your project is > started from > > > > > project root and data is located under it. > > > > > > > > > > If this breaks .Net, I am deeply sorry. > > > > > However, I think we should change .net to provide non-default > workdir > > > > > location when none is specified. > > > > > > > > > > Can you please clarify scenarios that are broken now? > > > > > > > > > > Regards, > > > > > > > > > > ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > > > > > > > > > > > Igniters, > > > > > > > > > > > > Looks like we made a mistake while implementing IGNITE-12057: > > > > > > `user.dir` is NOT user home directory, it is where JVM has been > started > > > > > > from, which is rather arbitrary. > > > > > > (Among other things this breaks Ignite.NET usage from tools like > > > > LINQPad, > > > > > > because `user.dir` ends up pointing to Program Files, which is > not > > > > > > writable without elevation) > > > > > > > > > > > > We should use `user.home` system property instead, see > > > > > > > > > > > > > > > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > > > > > > > > > > > Thoughts, objections? > > > > > > > > > > > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev < > > > > > ilya.kasnach...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hello again! > > > > > > > > > > > > > > Please note that I have updated release notes for IGNITE-12057 > as > > > > well > > > > > as > > > > > > > added them for my ticket. Release Engineers, please make sure > you > > > > > include > > > > > > > the latest one. > > > > > > > > > > > > > > Regards, > > > > > > > -- > > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev < > > > > > ilya.kasnach...@gmail.com > > > > > > >: > > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > I have pushed an
Re: Replacing default work dir from tmp to current dir
Folks, I am with Ilya here. I remind that we are talking not about general case for Ignite usage. Generally IGNITE_HOME should be defined. Otherwise we fallback to a default, and user.dir usually points to a directory where java launcher command was called (work dir). user.home seems to cause more surprises to me: * user.home can be undefined for JVM; * user.home can be not writable as well (e.g. some special service user). And as far as know other vendors usually place files required for an application in current work dir. чт, 3 окт. 2019 г. в 01:45, Denis Magda : > > I was always expecting this to be a user *home* directory that can be > resolved in any operating system and will work for any language supported > by Ignite. So, I'm with Pavel here. > > Alex G, what's your thinking? Sounds like we need to change this one more > time. > > - > Denis > > > On Wed, Oct 2, 2019 at 12:17 PM Pavel Tupitsyn wrote: > > > Everyone above agreed to `~/ignite/work`, then somehow we jumped to > > `user.dir/ignite/work`. > > To me `user.dir` looked like synonym for ~, but turns out this is not true. > > I think others may be confused in the same way. > > > > Denis Magda, Alexey Goncharuk, and others - please confirm that you > > understand that `user.dir` means current directory, not user home > > directory. > > > > In my opinion, this is very broken. Current work dir can be literally > > anything, e.g.: > > `cd / && ~/my-ignite-app/run.sh` will cause an attempt to create ignite dir > > in system root, and so on. > > > > > > > > On Wed, Oct 2, 2019 at 9:46 PM Ilya Kasnacheev > > wrote: > > > > > Hello! > > > > > > I think this is a sensible default and it was certainly not chosen by > > > mistake. It was intentional expectation that your project is started from > > > project root and data is located under it. > > > > > > If this breaks .Net, I am deeply sorry. > > > However, I think we should change .net to provide non-default workdir > > > location when none is specified. > > > > > > Can you please clarify scenarios that are broken now? > > > > > > Regards, > > > > > > ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > > > > > > > Igniters, > > > > > > > > Looks like we made a mistake while implementing IGNITE-12057: > > > > `user.dir` is NOT user home directory, it is where JVM has been started > > > > from, which is rather arbitrary. > > > > (Among other things this breaks Ignite.NET usage from tools like > > LINQPad, > > > > because `user.dir` ends up pointing to Program Files, which is not > > > > writable without elevation) > > > > > > > > We should use `user.home` system property instead, see > > > > > > > > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > > > > > > > Thoughts, objections? > > > > > > > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > Hello again! > > > > > > > > > > Please note that I have updated release notes for IGNITE-12057 as > > well > > > as > > > > > added them for my ticket. Release Engineers, please make sure you > > > include > > > > > the latest one. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > >: > > > > > > > > > > > Hello! > > > > > > > > > > > > I have pushed an amended fix to both master and ignite-2.7.6. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > > > > > > > > > > > >> Ilya, > > > > > >> > > > > > >> I forgot to push "Send for review" button. You can see my minor > > > > comment > > > > > >> now. > > > > > >> > > > > > >> - > > > > > >> Denis > > > > > >> > > > > > >> > > > > > >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < > > > > > >> ilya.kasnach...@gmail.com> > > > > > >> wrote: > > > > > >> > > > > > >> > Hello! > > > > > >> > > > > > > >> > Waiting for a minor comment from Denis, as soon as I see/fix it > > > I'm > > > > > >> going > > > > > >> > to commit. > > > > > >> > > > > > > >> > Regards, > > > > > >> > Ilya. > > > > > >> > -- > > > > > >> > Ilya Kasnacheev > > > > > >> > > > > > > >> > > > > > > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > > > > > >> alexey.goncha...@gmail.com > > > > > >> > >: > > > > > >> > > > > > > >> > > Hello Ilya, > > > > > >> > > > > > > > >> > > Just curious, when are you planning to commit your changes to > > > the > > > > > >> 2.7.6 > > > > > >> > > branch? > > > > > >> > > > > > > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > > > > > >> > > > > > > > >> > > > 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
Re: Replacing default work dir from tmp to current dir
As for .NET. Should not we define IGNITE_HOME for it? чт, 3 окт. 2019 г. в 12:13, Ivan Pavlukhin : > > Folks, > > I am with Ilya here. I remind that we are talking not about general > case for Ignite usage. Generally IGNITE_HOME should be defined. > Otherwise we fallback to a default, and user.dir usually points to a > directory where java launcher command was called (work dir). > > user.home seems to cause more surprises to me: > * user.home can be undefined for JVM; > * user.home can be not writable as well (e.g. some special service user). > > And as far as know other vendors usually place files required for an > application in current work dir. > > чт, 3 окт. 2019 г. в 01:45, Denis Magda : > > > > I was always expecting this to be a user *home* directory that can be > > resolved in any operating system and will work for any language supported > > by Ignite. So, I'm with Pavel here. > > > > Alex G, what's your thinking? Sounds like we need to change this one more > > time. > > > > - > > Denis > > > > > > On Wed, Oct 2, 2019 at 12:17 PM Pavel Tupitsyn wrote: > > > > > Everyone above agreed to `~/ignite/work`, then somehow we jumped to > > > `user.dir/ignite/work`. > > > To me `user.dir` looked like synonym for ~, but turns out this is not > > > true. > > > I think others may be confused in the same way. > > > > > > Denis Magda, Alexey Goncharuk, and others - please confirm that you > > > understand that `user.dir` means current directory, not user home > > > directory. > > > > > > In my opinion, this is very broken. Current work dir can be literally > > > anything, e.g.: > > > `cd / && ~/my-ignite-app/run.sh` will cause an attempt to create ignite > > > dir > > > in system root, and so on. > > > > > > > > > > > > On Wed, Oct 2, 2019 at 9:46 PM Ilya Kasnacheev > > > wrote: > > > > > > > Hello! > > > > > > > > I think this is a sensible default and it was certainly not chosen by > > > > mistake. It was intentional expectation that your project is started > > > > from > > > > project root and data is located under it. > > > > > > > > If this breaks .Net, I am deeply sorry. > > > > However, I think we should change .net to provide non-default workdir > > > > location when none is specified. > > > > > > > > Can you please clarify scenarios that are broken now? > > > > > > > > Regards, > > > > > > > > ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > > > > > > > > > Igniters, > > > > > > > > > > Looks like we made a mistake while implementing IGNITE-12057: > > > > > `user.dir` is NOT user home directory, it is where JVM has been > > > > > started > > > > > from, which is rather arbitrary. > > > > > (Among other things this breaks Ignite.NET usage from tools like > > > LINQPad, > > > > > because `user.dir` ends up pointing to Program Files, which is not > > > > > writable without elevation) > > > > > > > > > > We should use `user.home` system property instead, see > > > > > > > > > > > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > > > > > > > > > Thoughts, objections? > > > > > > > > > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello again! > > > > > > > > > > > > Please note that I have updated release notes for IGNITE-12057 as > > > well > > > > as > > > > > > added them for my ticket. Release Engineers, please make sure you > > > > include > > > > > > the latest one. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com > > > > > >: > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > I have pushed an amended fix to both master and ignite-2.7.6. > > > > > > > > > > > > > > Regards, > > > > > > > -- > > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > > > > > > > > > > > > > >> Ilya, > > > > > > >> > > > > > > >> I forgot to push "Send for review" button. You can see my minor > > > > > comment > > > > > > >> now. > > > > > > >> > > > > > > >> - > > > > > > >> Denis > > > > > > >> > > > > > > >> > > > > > > >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < > > > > > > >> ilya.kasnach...@gmail.com> > > > > > > >> wrote: > > > > > > >> > > > > > > >> > Hello! > > > > > > >> > > > > > > > >> > Waiting for a minor comment from Denis, as soon as I see/fix it > > > > I'm > > > > > > >> going > > > > > > >> > to commit. > > > > > > >> > > > > > > > >> > Regards, > > > > > > >> > Ilya. > > > > > > >> > -- > > > > > > >> > Ilya Kasnacheev > > > > > > >> > > > > > > > >> > > > > > > > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > > > > > > >> alexey.goncha...@gmail.com > > > > > > >> > >: > > > > > > >> > > > > > > > >> > > Hello Ilya, > > > > > > >> > > > > > > > > >> > > Just curious, when are you planning to commit your changes to > > > > the > > > > > > >> 2.7.6 > > > > > > >> >
Re: Replacing default work dir from tmp to current dir
Yes, my expectation was "~" to be the user home as well, too bad we missed this during the review. The current process directory is broken because a simple "cd" will make the persistent data disappear, which may be even worse than the temp directory. чт, 3 окт. 2019 г. в 01:45, Denis Magda : > I was always expecting this to be a user *home* directory that can be > resolved in any operating system and will work for any language supported > by Ignite. So, I'm with Pavel here. > > Alex G, what's your thinking? Sounds like we need to change this one more > time. > > - > Denis > > > On Wed, Oct 2, 2019 at 12:17 PM Pavel Tupitsyn > wrote: > > > Everyone above agreed to `~/ignite/work`, then somehow we jumped to > > `user.dir/ignite/work`. > > To me `user.dir` looked like synonym for ~, but turns out this is not > true. > > I think others may be confused in the same way. > > > > Denis Magda, Alexey Goncharuk, and others - please confirm that you > > understand that `user.dir` means current directory, not user home > > directory. > > > > In my opinion, this is very broken. Current work dir can be literally > > anything, e.g.: > > `cd / && ~/my-ignite-app/run.sh` will cause an attempt to create ignite > dir > > in system root, and so on. > > > > > > > > On Wed, Oct 2, 2019 at 9:46 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > wrote: > > > > > Hello! > > > > > > I think this is a sensible default and it was certainly not chosen by > > > mistake. It was intentional expectation that your project is started > from > > > project root and data is located under it. > > > > > > If this breaks .Net, I am deeply sorry. > > > However, I think we should change .net to provide non-default workdir > > > location when none is specified. > > > > > > Can you please clarify scenarios that are broken now? > > > > > > Regards, > > > > > > ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > > > > > > > Igniters, > > > > > > > > Looks like we made a mistake while implementing IGNITE-12057: > > > > `user.dir` is NOT user home directory, it is where JVM has been > started > > > > from, which is rather arbitrary. > > > > (Among other things this breaks Ignite.NET usage from tools like > > LINQPad, > > > > because `user.dir` ends up pointing to Program Files, which is not > > > > writable without elevation) > > > > > > > > We should use `user.home` system property instead, see > > > > > > > > > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > > > > > > > Thoughts, objections? > > > > > > > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > Hello again! > > > > > > > > > > Please note that I have updated release notes for IGNITE-12057 as > > well > > > as > > > > > added them for my ticket. Release Engineers, please make sure you > > > include > > > > > the latest one. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > >: > > > > > > > > > > > Hello! > > > > > > > > > > > > I have pushed an amended fix to both master and ignite-2.7.6. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > > > > > > > > > > > >> Ilya, > > > > > >> > > > > > >> I forgot to push "Send for review" button. You can see my minor > > > > comment > > > > > >> now. > > > > > >> > > > > > >> - > > > > > >> Denis > > > > > >> > > > > > >> > > > > > >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < > > > > > >> ilya.kasnach...@gmail.com> > > > > > >> wrote: > > > > > >> > > > > > >> > Hello! > > > > > >> > > > > > > >> > Waiting for a minor comment from Denis, as soon as I see/fix > it > > > I'm > > > > > >> going > > > > > >> > to commit. > > > > > >> > > > > > > >> > Regards, > > > > > >> > Ilya. > > > > > >> > -- > > > > > >> > Ilya Kasnacheev > > > > > >> > > > > > > >> > > > > > > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > > > > > >> alexey.goncha...@gmail.com > > > > > >> > >: > > > > > >> > > > > > > >> > > Hello Ilya, > > > > > >> > > > > > > > >> > > Just curious, when are you planning to commit your changes > to > > > the > > > > > >> 2.7.6 > > > > > >> > > branch? > > > > > >> > > > > > > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda >: > > > > > >> > > > > > > > >> > > > Ok, seems like we came to a consensus. Let’s ensure that > the > > > > path > > > > > >> for > > > > > >> > our > > > > > >> > > > work dir is user.dir/ignite/work and restart the vote. > > > > > >> > > > > > > > > >> > > > Denis > > > > > >> > > > > > > > > >> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < > > > > > >> > ilya.kasnach...@gmail.com> > > > > > >> > > > wrote: > > > > > >> > > > > > > > > >> > > > > Hello! > > > > > >> > > > > > > > > > >> > > > > I have took the liberty to implement the change to > > existing > > > >
Re: Replacing default work dir from tmp to current dir
I was always expecting this to be a user *home* directory that can be resolved in any operating system and will work for any language supported by Ignite. So, I'm with Pavel here. Alex G, what's your thinking? Sounds like we need to change this one more time. - Denis On Wed, Oct 2, 2019 at 12:17 PM Pavel Tupitsyn wrote: > Everyone above agreed to `~/ignite/work`, then somehow we jumped to > `user.dir/ignite/work`. > To me `user.dir` looked like synonym for ~, but turns out this is not true. > I think others may be confused in the same way. > > Denis Magda, Alexey Goncharuk, and others - please confirm that you > understand that `user.dir` means current directory, not user home > directory. > > In my opinion, this is very broken. Current work dir can be literally > anything, e.g.: > `cd / && ~/my-ignite-app/run.sh` will cause an attempt to create ignite dir > in system root, and so on. > > > > On Wed, Oct 2, 2019 at 9:46 PM Ilya Kasnacheev > wrote: > > > Hello! > > > > I think this is a sensible default and it was certainly not chosen by > > mistake. It was intentional expectation that your project is started from > > project root and data is located under it. > > > > If this breaks .Net, I am deeply sorry. > > However, I think we should change .net to provide non-default workdir > > location when none is specified. > > > > Can you please clarify scenarios that are broken now? > > > > Regards, > > > > ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > > > > > Igniters, > > > > > > Looks like we made a mistake while implementing IGNITE-12057: > > > `user.dir` is NOT user home directory, it is where JVM has been started > > > from, which is rather arbitrary. > > > (Among other things this breaks Ignite.NET usage from tools like > LINQPad, > > > because `user.dir` ends up pointing to Program Files, which is not > > > writable without elevation) > > > > > > We should use `user.home` system property instead, see > > > > > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > > > > > Thoughts, objections? > > > > > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > Hello again! > > > > > > > > Please note that I have updated release notes for IGNITE-12057 as > well > > as > > > > added them for my ticket. Release Engineers, please make sure you > > include > > > > the latest one. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > > > Hello! > > > > > > > > > > I have pushed an amended fix to both master and ignite-2.7.6. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > > > > > > > > > >> Ilya, > > > > >> > > > > >> I forgot to push "Send for review" button. You can see my minor > > > comment > > > > >> now. > > > > >> > > > > >> - > > > > >> Denis > > > > >> > > > > >> > > > > >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < > > > > >> ilya.kasnach...@gmail.com> > > > > >> wrote: > > > > >> > > > > >> > Hello! > > > > >> > > > > > >> > Waiting for a minor comment from Denis, as soon as I see/fix it > > I'm > > > > >> going > > > > >> > to commit. > > > > >> > > > > > >> > Regards, > > > > >> > Ilya. > > > > >> > -- > > > > >> > Ilya Kasnacheev > > > > >> > > > > > >> > > > > > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > > > > >> alexey.goncha...@gmail.com > > > > >> > >: > > > > >> > > > > > >> > > Hello Ilya, > > > > >> > > > > > > >> > > Just curious, when are you planning to commit your changes to > > the > > > > >> 2.7.6 > > > > >> > > branch? > > > > >> > > > > > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > > > > >> > > > > > > >> > > > Ok, seems like we came to a consensus. Let’s ensure that the > > > path > > > > >> for > > > > >> > our > > > > >> > > > work dir is user.dir/ignite/work and restart the vote. > > > > >> > > > > > > > >> > > > Denis > > > > >> > > > > > > > >> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < > > > > >> > ilya.kasnach...@gmail.com> > > > > >> > > > wrote: > > > > >> > > > > > > > >> > > > > Hello! > > > > >> > > > > > > > > >> > > > > I have took the liberty to implement the change to > existing > > > code > > > > >> base > > > > >> > > to > > > > >> > > > > remove concern about work/ directory: > > > > >> > > > > > > > > >> > > > > https://github.com/apache/ignite/pull/6816/files > > > > >> > > > > > > > > >> > > > > Some advocacy for this patch: > > > > >> > > > > - Minimal change. > > > > >> > > > > - Storing in user.dir/ignite/work (current directory, e.g. > > > > project > > > > >> > > root) > > > > >> > > > > which is consistent with behavior of unzipped binary > > release. > > > > >> > > > > - We can re-use user.dir/ignite for other uses in the > > future, > > > > >> such as > > > > >> > > > > storing logs there. > > > > >> > > > > >
Re: Replacing default work dir from tmp to current dir
Everyone above agreed to `~/ignite/work`, then somehow we jumped to `user.dir/ignite/work`. To me `user.dir` looked like synonym for ~, but turns out this is not true. I think others may be confused in the same way. Denis Magda, Alexey Goncharuk, and others - please confirm that you understand that `user.dir` means current directory, not user home directory. In my opinion, this is very broken. Current work dir can be literally anything, e.g.: `cd / && ~/my-ignite-app/run.sh` will cause an attempt to create ignite dir in system root, and so on. On Wed, Oct 2, 2019 at 9:46 PM Ilya Kasnacheev wrote: > Hello! > > I think this is a sensible default and it was certainly not chosen by > mistake. It was intentional expectation that your project is started from > project root and data is located under it. > > If this breaks .Net, I am deeply sorry. > However, I think we should change .net to provide non-default workdir > location when none is specified. > > Can you please clarify scenarios that are broken now? > > Regards, > > ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > > > Igniters, > > > > Looks like we made a mistake while implementing IGNITE-12057: > > `user.dir` is NOT user home directory, it is where JVM has been started > > from, which is rather arbitrary. > > (Among other things this breaks Ignite.NET usage from tools like LINQPad, > > because `user.dir` ends up pointing to Program Files, which is not > > writable without elevation) > > > > We should use `user.home` system property instead, see > > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > > > Thoughts, objections? > > > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > wrote: > > > > > Hello again! > > > > > > Please note that I have updated release notes for IGNITE-12057 as well > as > > > added them for my ticket. Release Engineers, please make sure you > include > > > the latest one. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > >: > > > > > > > Hello! > > > > > > > > I have pushed an amended fix to both master and ignite-2.7.6. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > > > > > > > >> Ilya, > > > >> > > > >> I forgot to push "Send for review" button. You can see my minor > > comment > > > >> now. > > > >> > > > >> - > > > >> Denis > > > >> > > > >> > > > >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < > > > >> ilya.kasnach...@gmail.com> > > > >> wrote: > > > >> > > > >> > Hello! > > > >> > > > > >> > Waiting for a minor comment from Denis, as soon as I see/fix it > I'm > > > >> going > > > >> > to commit. > > > >> > > > > >> > Regards, > > > >> > Ilya. > > > >> > -- > > > >> > Ilya Kasnacheev > > > >> > > > > >> > > > > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > > > >> alexey.goncha...@gmail.com > > > >> > >: > > > >> > > > > >> > > Hello Ilya, > > > >> > > > > > >> > > Just curious, when are you planning to commit your changes to > the > > > >> 2.7.6 > > > >> > > branch? > > > >> > > > > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > > > >> > > > > > >> > > > Ok, seems like we came to a consensus. Let’s ensure that the > > path > > > >> for > > > >> > our > > > >> > > > work dir is user.dir/ignite/work and restart the vote. > > > >> > > > > > > >> > > > Denis > > > >> > > > > > > >> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < > > > >> > ilya.kasnach...@gmail.com> > > > >> > > > wrote: > > > >> > > > > > > >> > > > > Hello! > > > >> > > > > > > > >> > > > > I have took the liberty to implement the change to existing > > code > > > >> base > > > >> > > to > > > >> > > > > remove concern about work/ directory: > > > >> > > > > > > > >> > > > > https://github.com/apache/ignite/pull/6816/files > > > >> > > > > > > > >> > > > > Some advocacy for this patch: > > > >> > > > > - Minimal change. > > > >> > > > > - Storing in user.dir/ignite/work (current directory, e.g. > > > project > > > >> > > root) > > > >> > > > > which is consistent with behavior of unzipped binary > release. > > > >> > > > > - We can re-use user.dir/ignite for other uses in the > future, > > > >> such as > > > >> > > > > storing logs there. > > > >> > > > > > > > >> > > > > I have to admit that my previous reaction to the change was > > too > > > >> > strong. > > > >> > > > It > > > >> > > > > turned out the default was user.dir/work (project root) and > > not > > > >> > > > > user.home/work (home dir with imminent Work collision). > > > >> > > > > Nevertheless, I think that after this change it would be > good > > > >> enough > > > >> > to > > > >> > > > > last for a few years. > > > >> > > > > > > > >> > > > > What do you think? > > > >> > > > > > > > >> > > > > Regards, > > > >> > > > > -- > > > >> > > > > Ilya Kasnacheev > > > >> > > > > > > > >> > > > > > > > >> > > > > вт, 27 авг.
Re: Replacing default work dir from tmp to current dir
Hello! I think this is a sensible default and it was certainly not chosen by mistake. It was intentional expectation that your project is started from project root and data is located under it. If this breaks .Net, I am deeply sorry. However, I think we should change .net to provide non-default workdir location when none is specified. Can you please clarify scenarios that are broken now? Regards, ср, 2 окт. 2019 г., 20:28 Pavel Tupitsyn : > Igniters, > > Looks like we made a mistake while implementing IGNITE-12057: > `user.dir` is NOT user home directory, it is where JVM has been started > from, which is rather arbitrary. > (Among other things this breaks Ignite.NET usage from tools like LINQPad, > because `user.dir` ends up pointing to Program Files, which is not > writable without elevation) > > We should use `user.home` system property instead, see > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > > Thoughts, objections? > > On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev > wrote: > > > Hello again! > > > > Please note that I have updated release notes for IGNITE-12057 as well as > > added them for my ticket. Release Engineers, please make sure you include > > the latest one. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev >: > > > > > Hello! > > > > > > I have pushed an amended fix to both master and ignite-2.7.6. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > > > > > >> Ilya, > > >> > > >> I forgot to push "Send for review" button. You can see my minor > comment > > >> now. > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < > > >> ilya.kasnach...@gmail.com> > > >> wrote: > > >> > > >> > Hello! > > >> > > > >> > Waiting for a minor comment from Denis, as soon as I see/fix it I'm > > >> going > > >> > to commit. > > >> > > > >> > Regards, > > >> > Ilya. > > >> > -- > > >> > Ilya Kasnacheev > > >> > > > >> > > > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > > >> alexey.goncha...@gmail.com > > >> > >: > > >> > > > >> > > Hello Ilya, > > >> > > > > >> > > Just curious, when are you planning to commit your changes to the > > >> 2.7.6 > > >> > > branch? > > >> > > > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > > >> > > > > >> > > > Ok, seems like we came to a consensus. Let’s ensure that the > path > > >> for > > >> > our > > >> > > > work dir is user.dir/ignite/work and restart the vote. > > >> > > > > > >> > > > Denis > > >> > > > > > >> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < > > >> > ilya.kasnach...@gmail.com> > > >> > > > wrote: > > >> > > > > > >> > > > > Hello! > > >> > > > > > > >> > > > > I have took the liberty to implement the change to existing > code > > >> base > > >> > > to > > >> > > > > remove concern about work/ directory: > > >> > > > > > > >> > > > > https://github.com/apache/ignite/pull/6816/files > > >> > > > > > > >> > > > > Some advocacy for this patch: > > >> > > > > - Minimal change. > > >> > > > > - Storing in user.dir/ignite/work (current directory, e.g. > > project > > >> > > root) > > >> > > > > which is consistent with behavior of unzipped binary release. > > >> > > > > - We can re-use user.dir/ignite for other uses in the future, > > >> such as > > >> > > > > storing logs there. > > >> > > > > > > >> > > > > I have to admit that my previous reaction to the change was > too > > >> > strong. > > >> > > > It > > >> > > > > turned out the default was user.dir/work (project root) and > not > > >> > > > > user.home/work (home dir with imminent Work collision). > > >> > > > > Nevertheless, I think that after this change it would be good > > >> enough > > >> > to > > >> > > > > last for a few years. > > >> > > > > > > >> > > > > What do you think? > > >> > > > > > > >> > > > > Regards, > > >> > > > > -- > > >> > > > > Ilya Kasnacheev > > >> > > > > > > >> > > > > > > >> > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < > > >> > > > alexey.goncha...@gmail.com > > >> > > > > >: > > >> > > > > > > >> > > > > > In the current state of the project, we cannot directly > > compare > > >> > > Ignite > > >> > > > > > setup process to the one of postgresql or another database. > In > > >> many > > >> > > > > Ignite > > >> > > > > > examples, an embedded node (even with persistence) is > started > > >> and > > >> > it > > >> > > is > > >> > > > > > supposed to run without any additional FS rights grants or > > init > > >> > > steps. > > >> > > > > This > > >> > > > > > may be changed in 3.0, but not in a maintenance release. If > we > > >> are > > >> > to > > >> > > > > > change the directory to /var/lib, I would rather fail Ignite > > >> node > > >> > > start > > >> > > > > > asking a user to explicitly provide work directory path. Let > > >> alone > > >> > > > > /var/lib > > >> > > > > > is not portable and I would not add an OS-switch to the code > > >>
Re: Replacing default work dir from tmp to current dir
Igniters, Looks like we made a mistake while implementing IGNITE-12057: `user.dir` is NOT user home directory, it is where JVM has been started from, which is rather arbitrary. (Among other things this breaks Ignite.NET usage from tools like LINQPad, because `user.dir` ends up pointing to Program Files, which is not writable without elevation) We should use `user.home` system property instead, see https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html Thoughts, objections? On Mon, Sep 2, 2019 at 1:57 PM Ilya Kasnacheev wrote: > Hello again! > > Please note that I have updated release notes for IGNITE-12057 as well as > added them for my ticket. Release Engineers, please make sure you include > the latest one. > > Regards, > -- > Ilya Kasnacheev > > > пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev : > > > Hello! > > > > I have pushed an amended fix to both master and ignite-2.7.6. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > > > >> Ilya, > >> > >> I forgot to push "Send for review" button. You can see my minor comment > >> now. > >> > >> - > >> Denis > >> > >> > >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com> > >> wrote: > >> > >> > Hello! > >> > > >> > Waiting for a minor comment from Denis, as soon as I see/fix it I'm > >> going > >> > to commit. > >> > > >> > Regards, > >> > Ilya. > >> > -- > >> > Ilya Kasnacheev > >> > > >> > > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > >> alexey.goncha...@gmail.com > >> > >: > >> > > >> > > Hello Ilya, > >> > > > >> > > Just curious, when are you planning to commit your changes to the > >> 2.7.6 > >> > > branch? > >> > > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > >> > > > >> > > > Ok, seems like we came to a consensus. Let’s ensure that the path > >> for > >> > our > >> > > > work dir is user.dir/ignite/work and restart the vote. > >> > > > > >> > > > Denis > >> > > > > >> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < > >> > ilya.kasnach...@gmail.com> > >> > > > wrote: > >> > > > > >> > > > > Hello! > >> > > > > > >> > > > > I have took the liberty to implement the change to existing code > >> base > >> > > to > >> > > > > remove concern about work/ directory: > >> > > > > > >> > > > > https://github.com/apache/ignite/pull/6816/files > >> > > > > > >> > > > > Some advocacy for this patch: > >> > > > > - Minimal change. > >> > > > > - Storing in user.dir/ignite/work (current directory, e.g. > project > >> > > root) > >> > > > > which is consistent with behavior of unzipped binary release. > >> > > > > - We can re-use user.dir/ignite for other uses in the future, > >> such as > >> > > > > storing logs there. > >> > > > > > >> > > > > I have to admit that my previous reaction to the change was too > >> > strong. > >> > > > It > >> > > > > turned out the default was user.dir/work (project root) and not > >> > > > > user.home/work (home dir with imminent Work collision). > >> > > > > Nevertheless, I think that after this change it would be good > >> enough > >> > to > >> > > > > last for a few years. > >> > > > > > >> > > > > What do you think? > >> > > > > > >> > > > > Regards, > >> > > > > -- > >> > > > > Ilya Kasnacheev > >> > > > > > >> > > > > > >> > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < > >> > > > alexey.goncha...@gmail.com > >> > > > > >: > >> > > > > > >> > > > > > In the current state of the project, we cannot directly > compare > >> > > Ignite > >> > > > > > setup process to the one of postgresql or another database. In > >> many > >> > > > > Ignite > >> > > > > > examples, an embedded node (even with persistence) is started > >> and > >> > it > >> > > is > >> > > > > > supposed to run without any additional FS rights grants or > init > >> > > steps. > >> > > > > This > >> > > > > > may be changed in 3.0, but not in a maintenance release. If we > >> are > >> > to > >> > > > > > change the directory to /var/lib, I would rather fail Ignite > >> node > >> > > start > >> > > > > > asking a user to explicitly provide work directory path. Let > >> alone > >> > > > > /var/lib > >> > > > > > is not portable and I would not add an OS-switch to the code > >> for no > >> > > > > reason. > >> > > > > > > >> > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya > >> that > >> > > > > writing > >> > > > > > large amounts of data in a hidden folder is a bad idea. > >> > > > > > > >> > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov < > dpav...@apache.org > >> >: > >> > > > > > > >> > > > > > > Hi Igniters, > >> > > > > > > > >> > > > > > > I agree that user home maybe not the best place from Linux > >> > > > perspective > >> > > > > > and > >> > > > > > > philosophy, but "user.home"/ignite/work is more or less > >> > portable. > >> > > > > > > > >> > > > > > > For the Linux environment, we can add a suggestion about > >> where to > >> > > > place > >> > > > > > > persisted data. For very first
Re: Replacing default work dir from tmp to current dir
Hello again! Please note that I have updated release notes for IGNITE-12057 as well as added them for my ticket. Release Engineers, please make sure you include the latest one. Regards, -- Ilya Kasnacheev пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev : > Hello! > > I have pushed an amended fix to both master and ignite-2.7.6. > > Regards, > -- > Ilya Kasnacheev > > > пт, 30 авг. 2019 г. в 21:48, Denis Magda : > >> Ilya, >> >> I forgot to push "Send for review" button. You can see my minor comment >> now. >> >> - >> Denis >> >> >> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >> wrote: >> >> > Hello! >> > >> > Waiting for a minor comment from Denis, as soon as I see/fix it I'm >> going >> > to commit. >> > >> > Regards, >> > Ilya. >> > -- >> > Ilya Kasnacheev >> > >> > >> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < >> alexey.goncha...@gmail.com >> > >: >> > >> > > Hello Ilya, >> > > >> > > Just curious, when are you planning to commit your changes to the >> 2.7.6 >> > > branch? >> > > >> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : >> > > >> > > > Ok, seems like we came to a consensus. Let’s ensure that the path >> for >> > our >> > > > work dir is user.dir/ignite/work and restart the vote. >> > > > >> > > > Denis >> > > > >> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < >> > ilya.kasnach...@gmail.com> >> > > > wrote: >> > > > >> > > > > Hello! >> > > > > >> > > > > I have took the liberty to implement the change to existing code >> base >> > > to >> > > > > remove concern about work/ directory: >> > > > > >> > > > > https://github.com/apache/ignite/pull/6816/files >> > > > > >> > > > > Some advocacy for this patch: >> > > > > - Minimal change. >> > > > > - Storing in user.dir/ignite/work (current directory, e.g. project >> > > root) >> > > > > which is consistent with behavior of unzipped binary release. >> > > > > - We can re-use user.dir/ignite for other uses in the future, >> such as >> > > > > storing logs there. >> > > > > >> > > > > I have to admit that my previous reaction to the change was too >> > strong. >> > > > It >> > > > > turned out the default was user.dir/work (project root) and not >> > > > > user.home/work (home dir with imminent Work collision). >> > > > > Nevertheless, I think that after this change it would be good >> enough >> > to >> > > > > last for a few years. >> > > > > >> > > > > What do you think? >> > > > > >> > > > > Regards, >> > > > > -- >> > > > > Ilya Kasnacheev >> > > > > >> > > > > >> > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < >> > > > alexey.goncha...@gmail.com >> > > > > >: >> > > > > >> > > > > > In the current state of the project, we cannot directly compare >> > > Ignite >> > > > > > setup process to the one of postgresql or another database. In >> many >> > > > > Ignite >> > > > > > examples, an embedded node (even with persistence) is started >> and >> > it >> > > is >> > > > > > supposed to run without any additional FS rights grants or init >> > > steps. >> > > > > This >> > > > > > may be changed in 3.0, but not in a maintenance release. If we >> are >> > to >> > > > > > change the directory to /var/lib, I would rather fail Ignite >> node >> > > start >> > > > > > asking a user to explicitly provide work directory path. Let >> alone >> > > > > /var/lib >> > > > > > is not portable and I would not add an OS-switch to the code >> for no >> > > > > reason. >> > > > > > >> > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya >> that >> > > > > writing >> > > > > > large amounts of data in a hidden folder is a bad idea. >> > > > > > >> > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov > >: >> > > > > > >> > > > > > > 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 < >> xxt...@gmail.com >> > >: >> > > > > > > >> > > > > > > > Or instead of a WARNING, we can add a suggestion with a >> > > > > recommendation >> > > > > > > > for the production environment. >> > > > > > > > >> > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov < >> mr.wei...@gmail.com >> > >: >> > > > > > > > > >> > > > > > > > > /opt is either does not exist on fresh system, or has the >> > same >> > > > > > > > restriction: no user access without admin intervention. >> > > > > > > > > /usr/local, /var/lib, etc. — all this is implemented in >> our >> > > DEB / >> > > > > RPM >> > > > > > > > packages already. >> > > > > > > > > >> > > > > > >
Re: Replacing default work dir from tmp to current dir
Hello! I have pushed an amended fix to both master and ignite-2.7.6. Regards, -- Ilya Kasnacheev пт, 30 авг. 2019 г. в 21:48, Denis Magda : > Ilya, > > I forgot to push "Send for review" button. You can see my minor comment > now. > > - > Denis > > > On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev > > wrote: > > > Hello! > > > > Waiting for a minor comment from Denis, as soon as I see/fix it I'm going > > to commit. > > > > Regards, > > Ilya. > > -- > > Ilya Kasnacheev > > > > > > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > Hello Ilya, > > > > > > Just curious, when are you planning to commit your changes to the 2.7.6 > > > branch? > > > > > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > > > > > > > Ok, seems like we came to a consensus. Let’s ensure that the path for > > our > > > > work dir is user.dir/ignite/work and restart the vote. > > > > > > > > Denis > > > > > > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > I have took the liberty to implement the change to existing code > base > > > to > > > > > remove concern about work/ directory: > > > > > > > > > > https://github.com/apache/ignite/pull/6816/files > > > > > > > > > > Some advocacy for this patch: > > > > > - Minimal change. > > > > > - Storing in user.dir/ignite/work (current directory, e.g. project > > > root) > > > > > which is consistent with behavior of unzipped binary release. > > > > > - We can re-use user.dir/ignite for other uses in the future, such > as > > > > > storing logs there. > > > > > > > > > > I have to admit that my previous reaction to the change was too > > strong. > > > > It > > > > > turned out the default was user.dir/work (project root) and not > > > > > user.home/work (home dir with imminent Work collision). > > > > > Nevertheless, I think that after this change it would be good > enough > > to > > > > > last for a few years. > > > > > > > > > > What do you think? > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com > > > > > >: > > > > > > > > > > > In the current state of the project, we cannot directly compare > > > Ignite > > > > > > setup process to the one of postgresql or another database. In > many > > > > > Ignite > > > > > > examples, an embedded node (even with persistence) is started and > > it > > > is > > > > > > supposed to run without any additional FS rights grants or init > > > steps. > > > > > This > > > > > > may be changed in 3.0, but not in a maintenance release. If we > are > > to > > > > > > change the directory to /var/lib, I would rather fail Ignite node > > > start > > > > > > asking a user to explicitly provide work directory path. Let > alone > > > > > /var/lib > > > > > > is not portable and I would not add an OS-switch to the code for > no > > > > > reason. > > > > > > > > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya > that > > > > > writing > > > > > > large amounts of data in a hidden folder is a bad idea. > > > > > > > > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov >: > > > > > > > > > > > > > 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 < > xxt...@gmail.com > > >: > > > > > > > > > > > > > > > Or instead of a WARNING, we can add a suggestion with a > > > > > recommendation > > > > > > > > for the production environment. > > > > > > > > > > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov < > mr.wei...@gmail.com > > >: > > > > > > > > > > > > > > > > > > /opt is either does not exist on fresh system, or has the > > same > > > > > > > > restriction: no user access without admin intervention. > > > > > > > > > /usr/local, /var/lib, etc. — all this is implemented in our > > > DEB / > > > > > RPM > > > > > > > > packages already. > > > > > > > > > > > > > > > > > > For ZIP installation %HOME% seems to be the best approach > for > > > > > > "2-click" > > > > > > > > launch. > > > > > > > > > Later user can update preferences and set working dir to > > > whatever > > > > > > > > directory he would like. > > > > > > > > > > > > > > > > > > Also — we can put WARNING message to log noting that > WORK_DIR > > > is > > > > > set > > > > > > to > > > > > > > > default. > > > > > > > > > > > > > > > > > > > On 27 Aug 2019, at 10:16,
Re: Replacing default work dir from tmp to current dir
Ilya, I forgot to push "Send for review" button. You can see my minor comment now. - Denis On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev wrote: > Hello! > > Waiting for a minor comment from Denis, as soon as I see/fix it I'm going > to commit. > > Regards, > Ilya. > -- > Ilya Kasnacheev > > > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk >: > > > Hello Ilya, > > > > Just curious, when are you planning to commit your changes to the 2.7.6 > > branch? > > > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > > > > > Ok, seems like we came to a consensus. Let’s ensure that the path for > our > > > work dir is user.dir/ignite/work and restart the vote. > > > > > > Denis > > > > > > On Tuesday, August 27, 2019, Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > Hello! > > > > > > > > I have took the liberty to implement the change to existing code base > > to > > > > remove concern about work/ directory: > > > > > > > > https://github.com/apache/ignite/pull/6816/files > > > > > > > > Some advocacy for this patch: > > > > - Minimal change. > > > > - Storing in user.dir/ignite/work (current directory, e.g. project > > root) > > > > which is consistent with behavior of unzipped binary release. > > > > - We can re-use user.dir/ignite for other uses in the future, such as > > > > storing logs there. > > > > > > > > I have to admit that my previous reaction to the change was too > strong. > > > It > > > > turned out the default was user.dir/work (project root) and not > > > > user.home/work (home dir with imminent Work collision). > > > > Nevertheless, I think that after this change it would be good enough > to > > > > last for a few years. > > > > > > > > What do you think? > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > > >: > > > > > > > > > In the current state of the project, we cannot directly compare > > Ignite > > > > > setup process to the one of postgresql or another database. In many > > > > Ignite > > > > > examples, an embedded node (even with persistence) is started and > it > > is > > > > > supposed to run without any additional FS rights grants or init > > steps. > > > > This > > > > > may be changed in 3.0, but not in a maintenance release. If we are > to > > > > > change the directory to /var/lib, I would rather fail Ignite node > > start > > > > > asking a user to explicitly provide work directory path. Let alone > > > > /var/lib > > > > > is not portable and I would not add an OS-switch to the code for no > > > > reason. > > > > > > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya that > > > > writing > > > > > large amounts of data in a hidden folder is a bad idea. > > > > > > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov : > > > > > > > > > > > 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 >: > > > > > > > > > > > > > Or instead of a WARNING, we can add a suggestion with a > > > > recommendation > > > > > > > for the production environment. > > > > > > > > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov >: > > > > > > > > > > > > > > > > /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 > > > > > > > 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
Re: Replacing default work dir from tmp to current dir
Hello! Waiting for a minor comment from Denis, as soon as I see/fix it I'm going to commit. Regards, Ilya. -- Ilya Kasnacheev пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk : > Hello Ilya, > > Just curious, when are you planning to commit your changes to the 2.7.6 > branch? > > ср, 28 авг. 2019 г. в 04:57, Denis Magda : > > > 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 > > wrote: > > > > > Hello! > > > > > > I have took the liberty to implement the change to existing code base > to > > > remove concern about work/ directory: > > > > > > https://github.com/apache/ignite/pull/6816/files > > > > > > Some advocacy for this patch: > > > - Minimal change. > > > - Storing in user.dir/ignite/work (current directory, e.g. project > root) > > > which is consistent with behavior of unzipped binary release. > > > - We can re-use user.dir/ignite for other uses in the future, such as > > > storing logs there. > > > > > > I have to admit that my previous reaction to the change was too strong. > > It > > > turned out the default was user.dir/work (project root) and not > > > user.home/work (home dir with imminent Work collision). > > > Nevertheless, I think that after this change it would be good enough to > > > last for a few years. > > > > > > What do you think? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < > > alexey.goncha...@gmail.com > > > >: > > > > > > > In the current state of the project, we cannot directly compare > Ignite > > > > setup process to the one of postgresql or another database. In many > > > Ignite > > > > examples, an embedded node (even with persistence) is started and it > is > > > > supposed to run without any additional FS rights grants or init > steps. > > > This > > > > may be changed in 3.0, but not in a maintenance release. If we are to > > > > change the directory to /var/lib, I would rather fail Ignite node > start > > > > asking a user to explicitly provide work directory path. Let alone > > > /var/lib > > > > is not portable and I would not add an OS-switch to the code for no > > > reason. > > > > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya that > > > writing > > > > large amounts of data in a hidden folder is a bad idea. > > > > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov : > > > > > > > > > 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 : > > > > > > > > > > > Or instead of a WARNING, we can add a suggestion with a > > > recommendation > > > > > > for the production environment. > > > > > > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > > > > > > > > > > > > > /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 > > > > > > 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 < > > > > > > dma...@apache.org>: > > > > > > > >> > > > > > > > >> Igniters, > > > > > > > >> > > > > > > > >> I can't disagree with
Re: Replacing default work dir from tmp to current dir
Hello Ilya, Just curious, when are you planning to commit your changes to the 2.7.6 branch? ср, 28 авг. 2019 г. в 04:57, Denis Magda : > 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 > wrote: > > > Hello! > > > > I have took the liberty to implement the change to existing code base to > > remove concern about work/ directory: > > > > https://github.com/apache/ignite/pull/6816/files > > > > Some advocacy for this patch: > > - Minimal change. > > - Storing in user.dir/ignite/work (current directory, e.g. project root) > > which is consistent with behavior of unzipped binary release. > > - We can re-use user.dir/ignite for other uses in the future, such as > > storing logs there. > > > > I have to admit that my previous reaction to the change was too strong. > It > > turned out the default was user.dir/work (project root) and not > > user.home/work (home dir with imminent Work collision). > > Nevertheless, I think that after this change it would be good enough to > > last for a few years. > > > > What do you think? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > In the current state of the project, we cannot directly compare Ignite > > > setup process to the one of postgresql or another database. In many > > Ignite > > > examples, an embedded node (even with persistence) is started and it is > > > supposed to run without any additional FS rights grants or init steps. > > This > > > may be changed in 3.0, but not in a maintenance release. If we are to > > > change the directory to /var/lib, I would rather fail Ignite node start > > > asking a user to explicitly provide work directory path. Let alone > > /var/lib > > > is not portable and I would not add an OS-switch to the code for no > > reason. > > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya that > > writing > > > large amounts of data in a hidden folder is a bad idea. > > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov : > > > > > > > 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 : > > > > > > > > > Or instead of a WARNING, we can add a suggestion with a > > recommendation > > > > > for the production environment. > > > > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > > > > > > > > > > > /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 > > > > > 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 < > > > > > dma...@apache.org>: > > > > > > >> > > > > > > >> Igniters, > > > > > > >> > > > > > > >> I can't disagree with Nikolay that, as a database, Ignite > needs > > to > > > > > persist > > > > > > >> changes to a folder different from "user.home" one. But with > the > > > > > current > > > > > > >> rate of project growth and adoption, I would encourage us to > > > > > eliminate any > > > > > > >> possible obstacles a user might come across during the getting > > > > started > > > > > > >> phase with Ignite. Unfortunately, folders different from > > > "user.home" > > > > > imply
Re: Replacing default work dir from tmp to current dir
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 : > 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 > wrote: > > > Hello! > > > > I have took the liberty to implement the change to existing code base to > > remove concern about work/ directory: > > > > https://github.com/apache/ignite/pull/6816/files > > > > Some advocacy for this patch: > > - Minimal change. > > - Storing in user.dir/ignite/work (current directory, e.g. project root) > > which is consistent with behavior of unzipped binary release. > > - We can re-use user.dir/ignite for other uses in the future, such as > > storing logs there. > > > > I have to admit that my previous reaction to the change was too strong. > It > > turned out the default was user.dir/work (project root) and not > > user.home/work (home dir with imminent Work collision). > > Nevertheless, I think that after this change it would be good enough to > > last for a few years. > > > > What do you think? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > In the current state of the project, we cannot directly compare Ignite > > > setup process to the one of postgresql or another database. In many > > Ignite > > > examples, an embedded node (even with persistence) is started and it is > > > supposed to run without any additional FS rights grants or init steps. > > This > > > may be changed in 3.0, but not in a maintenance release. If we are to > > > change the directory to /var/lib, I would rather fail Ignite node start > > > asking a user to explicitly provide work directory path. Let alone > > /var/lib > > > is not portable and I would not add an OS-switch to the code for no > > reason. > > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya that > > writing > > > large amounts of data in a hidden folder is a bad idea. > > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov : > > > > > > > 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 : > > > > > > > > > Or instead of a WARNING, we can add a suggestion with a > > recommendation > > > > > for the production environment. > > > > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > > > > > > > > > > > /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 > > > > > 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 < > > > > > dma...@apache.org>: > > > > > > >> > > > > > > >> Igniters, > > > > > > >> > > > > > > >> I can't disagree with Nikolay that, as a database, Ignite > needs > > to > > > > > persist > > > > > > >> changes to a folder different from "user.home" one. But with > the > > > > > current > > > > > > >> rate of project growth and adoption, I would encourage us to > > > > > eliminate any > > > > > > >> possible obstacles a user might come across during the getting > > > > started > > > > > > >> phase with Ignite. Unfortunately, folders different from > >
Re: Replacing default work dir from tmp to current dir
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 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 >: > > > 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 : > > > > > 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 : > > > > > > > Or instead of a WARNING, we can add a suggestion with a > recommendation > > > > for the production environment. > > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > > > > > > > > > /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 > > > > 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 < > > > > dma...@apache.org>: > > > > > >> > > > > > >> Igniters, > > > > > >> > > > > > >> I can't disagree with Nikolay that, as a database, Ignite needs > to > > > > persist > > > > > >> changes to a folder different from "user.home" one. But with the > > > > current > > > > > >> rate of project growth and adoption, I would encourage us to > > > > eliminate any > > > > > >> possible obstacles a user might come across during the getting > > > started > > > > > >> phase with Ignite. Unfortunately, folders different from > > "user.home" > > > > imply > > > > > >> a significant restriction - the user needs to allow access to > > > folders > > > > like > > > > > >> /lib, /etc; which can make every getting started demo or app > fail. > > > > > >> > > > > > >> Thus, today, I'm casting my vote for "user.home"/ignite/work > > > > directory. > > > > > >> Please don't forget about Windows and MacOS. > > > > > >> > > > > > >> - > > > > > >> Denis > > > > > >> > > > > > >> > > > > > >> On Mon, Aug 26,
Re: Replacing default work dir from tmp to current dir
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 : > 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 : > > > 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 : > > > > > Or instead of a WARNING, we can add a suggestion with a recommendation > > > for the production environment. > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > > > > > > > /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 > > > 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 < > > > dma...@apache.org>: > > > > >> > > > > >> Igniters, > > > > >> > > > > >> I can't disagree with Nikolay that, as a database, Ignite needs to > > > persist > > > > >> changes to a folder different from "user.home" one. But with the > > > current > > > > >> rate of project growth and adoption, I would encourage us to > > > eliminate any > > > > >> possible obstacles a user might come across during the getting > > started > > > > >> phase with Ignite. Unfortunately, folders different from > "user.home" > > > imply > > > > >> a significant restriction - the user needs to allow access to > > folders > > > like > > > > >> /lib, /etc; which can make every getting started demo or app fail. > > > > >> > > > > >> Thus, today, I'm casting my vote for "user.home"/ignite/work > > > directory. > > > > >> Please don't forget about Windows and MacOS. > > > > >> > > > > >> - > > > > >> Denis > > > > >> > > > > >> > > > > >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < > > ptupit...@apache.org > > > > wrote: > > > > >> > > > > >>> +1 for ~/.ignite/work > > > > >>> > > > > >>> As Petr mentioned above, this translates well to Windows and > MacOS > > > too, we > > > > >>> can use "home directory" term in documentation and it works for > any > > > OS. > > > > >>> > > > > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < > > > nizhi...@apache.org > > > > > >>> wrote: > > > > >>> > > > >
Re: Replacing default work dir from tmp to current dir
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 : > 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 : > > > Or instead of a WARNING, we can add a suggestion with a recommendation > > for the production environment. > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > > > > > /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 > > 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 < > > dma...@apache.org>: > > > >> > > > >> Igniters, > > > >> > > > >> I can't disagree with Nikolay that, as a database, Ignite needs to > > persist > > > >> changes to a folder different from "user.home" one. But with the > > current > > > >> rate of project growth and adoption, I would encourage us to > > eliminate any > > > >> possible obstacles a user might come across during the getting > started > > > >> phase with Ignite. Unfortunately, folders different from "user.home" > > imply > > > >> a significant restriction - the user needs to allow access to > folders > > like > > > >> /lib, /etc; which can make every getting started demo or app fail. > > > >> > > > >> Thus, today, I'm casting my vote for "user.home"/ignite/work > > directory. > > > >> Please don't forget about Windows and MacOS. > > > >> > > > >> - > > > >> Denis > > > >> > > > >> > > > >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < > ptupit...@apache.org > > > wrote: > > > >> > > > >>> +1 for ~/.ignite/work > > > >>> > > > >>> As Petr mentioned above, this translates well to Windows and MacOS > > too, we > > > >>> can use "home directory" term in documentation and it works for any > > OS. > > > >>> > > > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < > > nizhi...@apache.org > > > > >>> wrote: > > > >>> > > > AFAIK server admin expects software will store it's data in /var/ > > > directory, not in /home directory. > > > > > > > In Docker age, packages are becoming extinct. > > > > > > I don't agree with that, but seems, it's not a subject of > > discussion. :) > > > > > > > we don't even have very good packages today > > > > > > Why do you think we don't have good packages? > > > What is wrong with the current one? > > > > > > > I also think we should not copy what other DBMS do since their > > > ease-of-use > > > > is usually lacking > > > > > > We should define 'easy-of-use' here. > > > My experience with the modern dbms(postgres and mysql) is > different. > > > > > > > > > В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет: > > > > Hello! > > > > > > > > I think it is 2., because if a node is run from Ignite binary > > > distribution > > > > it has its root as a ignite work directory. I think it it another > > > argument > > >
Re: Replacing default work dir from tmp to current dir
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 : > Or instead of a WARNING, we can add a suggestion with a recommendation > for the production environment. > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > > > /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 > 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 < > dma...@apache.org>: > > >> > > >> Igniters, > > >> > > >> I can't disagree with Nikolay that, as a database, Ignite needs to > persist > > >> changes to a folder different from "user.home" one. But with the > current > > >> rate of project growth and adoption, I would encourage us to > eliminate any > > >> possible obstacles a user might come across during the getting started > > >> phase with Ignite. Unfortunately, folders different from "user.home" > imply > > >> a significant restriction - the user needs to allow access to folders > like > > >> /lib, /etc; which can make every getting started demo or app fail. > > >> > > >> Thus, today, I'm casting my vote for "user.home"/ignite/work > directory. > > >> Please don't forget about Windows and MacOS. > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < ptupit...@apache.org > > wrote: > > >> > > >>> +1 for ~/.ignite/work > > >>> > > >>> As Petr mentioned above, this translates well to Windows and MacOS > too, we > > >>> can use "home directory" term in documentation and it works for any > OS. > > >>> > > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < > nizhi...@apache.org > > > >>> wrote: > > >>> > > AFAIK server admin expects software will store it's data in /var/ > > directory, not in /home directory. > > > > > In Docker age, packages are becoming extinct. > > > > I don't agree with that, but seems, it's not a subject of > discussion. :) > > > > > we don't even have very good packages today > > > > Why do you think we don't have good packages? > > What is wrong with the current one? > > > > > I also think we should not copy what other DBMS do since their > > ease-of-use > > > is usually lacking > > > > We should define 'easy-of-use' here. > > My experience with the modern dbms(postgres and mysql) is different. > > > > > > В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет: > > > Hello! > > > > > > I think it is 2., because if a node is run from Ignite binary > > distribution > > > it has its root as a ignite work directory. I think it it another > > argument > > > for keeping data under current dir - Ignite binary distribution > already > > > does it, why should embedded scenario be different? > > > > > > In Docker age, packages are becoming extinct. Nobody wants them > > >>> anymore, > > > anyway. I don't see why we should aim for those since we don't even > > >>> have > > > very good packages today, and nobody wants to contribute towards > their > > > improvement. > > > > > > I also think we should not copy what other DBMS do since their > > ease-of-use > > > is usually lacking (this is from someone who had to support mysql > and > > pgsql > > > deployments). > > > > > > Regards, > > > > >>> > > > > > > > > > -- > > > Zhenya Stanilovsky > > >
Re: Replacing default work dir from tmp to current dir
Or instead of a WARNING, we can add a suggestion with a recommendation for the production environment. вт, 27 авг. 2019 г. в 11:41, Petr Ivanov : > > /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 > > 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 > >> : > >> > >> 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 < ptupit...@apache.org > > >> wrote: > >> > >>> +1 for ~/.ignite/work > >>> > >>> As Petr mentioned above, this translates well to Windows and MacOS too, we > >>> can use "home directory" term in documentation and it works for any OS. > >>> > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < nizhi...@apache.org > > >>> wrote: > >>> > AFAIK server admin expects software will store it's data in /var/ > directory, not in /home directory. > > > In Docker age, packages are becoming extinct. > > I don't agree with that, but seems, it's not a subject of discussion. :) > > > we don't even have very good packages today > > Why do you think we don't have good packages? > What is wrong with the current one? > > > I also think we should not copy what other DBMS do since their > ease-of-use > > is usually lacking > > We should define 'easy-of-use' here. > My experience with the modern dbms(postgres and mysql) is different. > > > В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет: > > Hello! > > > > I think it is 2., because if a node is run from Ignite binary > distribution > > it has its root as a ignite work directory. I think it it another > argument > > for keeping data under current dir - Ignite binary distribution already > > does it, why should embedded scenario be different? > > > > In Docker age, packages are becoming extinct. Nobody wants them > >>> anymore, > > anyway. I don't see why we should aim for those since we don't even > >>> have > > very good packages today, and nobody wants to contribute towards their > > improvement. > > > > I also think we should not copy what other DBMS do since their > ease-of-use > > is usually lacking (this is from someone who had to support mysql and > pgsql > > deployments). > > > > Regards, > > >>> > > > > > > -- > > Zhenya Stanilovsky >
Re: Replacing default work dir from tmp to current dir
/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 > 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 >> : >> >> 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 < ptupit...@apache.org > >> wrote: >> >>> +1 for ~/.ignite/work >>> >>> As Petr mentioned above, this translates well to Windows and MacOS too, we >>> can use "home directory" term in documentation and it works for any OS. >>> >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < nizhi...@apache.org > >>> wrote: >>> AFAIK server admin expects software will store it's data in /var/ directory, not in /home directory. > In Docker age, packages are becoming extinct. I don't agree with that, but seems, it's not a subject of discussion. :) > we don't even have very good packages today Why do you think we don't have good packages? What is wrong with the current one? > I also think we should not copy what other DBMS do since their ease-of-use > is usually lacking We should define 'easy-of-use' here. My experience with the modern dbms(postgres and mysql) is different. В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет: > Hello! > > I think it is 2., because if a node is run from Ignite binary distribution > it has its root as a ignite work directory. I think it it another argument > for keeping data under current dir - Ignite binary distribution already > does it, why should embedded scenario be different? > > In Docker age, packages are becoming extinct. Nobody wants them >>> anymore, > anyway. I don't see why we should aim for those since we don't even >>> have > very good packages today, and nobody wants to contribute towards their > improvement. > > I also think we should not copy what other DBMS do since their ease-of-use > is usually lacking (this is from someone who had to support mysql and pgsql > deployments). > > Regards, >>> > > > -- > Zhenya Stanilovsky
Re: Replacing default work dir from tmp to current dir
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 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 > 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, > > >
Re: Replacing default work dir from tmp to current dir
+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 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, >
Re: Replacing default work dir from tmp to current dir
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, signature.asc Description: This is a digitally signed message part
Re: Replacing default work dir from tmp to current dir
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 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 :
>
>> 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 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
>> wrote:
>
> +1 for '/var/lib/ignite'
>
> В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
>> +1 for '~/.ignite/work'
>>
>> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov >> :
>>
>>> 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" :
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,
>>>
>>>
>>
Re: Replacing default work dir from tmp to current dir
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 : > 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, >
Re: Replacing default work dir from tmp to current dir
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 :
> 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 :
>
> > 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
> 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
> > wrote:
> > > > >
> > > > > +1 for '/var/lib/ignite'
> > > > >
> > > > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > > > +1 for '~/.ignite/work'
> > > > > >
> > > > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <
> kaa@yandex.ru
> > >:
> > > > > >
> > > > > > > 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" :
> > > > > > > > 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
>
Re: Replacing default work dir from tmp to current dir
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 :
> 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 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
> wrote:
> > > >
> > > > +1 for '/var/lib/ignite'
> > > >
> > > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > > +1 for '~/.ignite/work'
> > > > >
> > > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov >:
> > > > >
> > > > > > 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" :
> > > > > > > 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,
> > > > > >
> > > > > >
> > >
> > >
>
Re: Replacing default work dir from tmp to current dir
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 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 wrote:
> > >
> > > +1 for '/var/lib/ignite'
> > >
> > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > +1 for '~/.ignite/work'
> > > >
> > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
> > > >
> > > > > 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" :
> > > > > > 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,
> > > > >
> > > > >
> >
> >
Re: Replacing default work dir from tmp to current dir
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 wrote:
> >
> > +1 for '/var/lib/ignite'
> >
> > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > +1 for '~/.ignite/work'
> > >
> > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
> > >
> > > > 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" :
> > > > > 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,
> > > >
> > > >
>
>
signature.asc
Description: This is a digitally signed message part
Re: Replacing default work dir from tmp to current dir
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 wrote:
>
> +1 for '/var/lib/ignite'
>
> В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
>> +1 for '~/.ignite/work'
>>
>> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
>>
>>> 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" :
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,
>>>
>>>
Re: Replacing default work dir from tmp to current dir
+1 for '/var/lib/ignite'
В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> +1 for '~/.ignite/work'
>
> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
>
> > 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" :
> > > 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,
> >
> >
signature.asc
Description: This is a digitally signed message part
Re: Replacing default work dir from tmp to current dir
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 :
> +1 for '~/.ignite/work'
>
> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
>
> > 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" :
> > > 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,
> >
> >
>
Re: Replacing default work dir from tmp to current dir
+1 for '~/.ignite/work'
пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
> 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" :
> > 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,
>
>
Re: Replacing default work dir from tmp to current dir
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" :
> 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,
Re: Replacing default work dir from tmp to current dir
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, signature.asc Description: This is a digitally signed message part
Re: Replacing default work dir from tmp to current dir
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 : > 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, >
Re: Replacing default work dir from tmp to current dir
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, signature.asc Description: This is a digitally signed message part
Re: Replacing default work dir from tmp to current dir
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 : > 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 > 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, Павлухин Иван : > > > > > > > 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 : > > > > > > > > > > > +1 for the user.dir as a default one. > > > > > > > > > > > > Denis > > > > > > > > > > > > On Monday, August 12, 2019, Dmitriy Pavlov > > > > > > 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
Re: Replacing default work dir from tmp to current dir
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 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, Павлухин Иван : > > > > > 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 : > > > > 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 : > > > > > > > > > +1 for the user.dir as a default one. > > > > > > > > > > Denis > > > > > > > > > > On Monday, August 12, 2019, Dmitriy Pavlov > > > > 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 : > > > > > > > > > > > > > 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 > > > > > > > > > > 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 > > >
Re: Replacing default work dir from tmp to current dir
I was certainly expecting ~/ignite/work too, not just ~/work On Mon, Aug 26, 2019 at 10:19 AM Dmitriy Pavlov 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, Павлухин Иван : > > > 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 : > > > 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 : > > > > > >> +1 for the user.dir as a default one. > > >> > > >> Denis > > >> > > >> On Monday, August 12, 2019, Dmitriy Pavlov > 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 : > > >> > > > >> > > 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 > > >> 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
Re: Replacing default work dir from tmp to current dir
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, Павлухин Иван :
> 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 :
> > 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 :
> >
> >> +1 for the user.dir as a default one.
> >>
> >> Denis
> >>
> >> On Monday, August 12, 2019, Dmitriy Pavlov 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 :
> >> >
> >> > > 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
> >> 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
> >> > > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > >
Re: Replacing default work dir from tmp to current dir
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 :
> 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 :
>
>> +1 for the user.dir as a default one.
>>
>> Denis
>>
>> On Monday, August 12, 2019, Dmitriy Pavlov 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 :
>> >
>> > > 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
>> 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
Re: Replacing default work dir from tmp to current dir
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 :
> +1 for the user.dir as a default one.
>
> Denis
>
> On Monday, August 12, 2019, Dmitriy Pavlov 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 :
> >
> > > 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
> 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
>
Re: Replacing default work dir from tmp to current dir
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 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 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 :
> >>
> >>> 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 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
> >>
>
>
> >
Re: Replacing default work dir from tmp to current dir
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 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 :
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 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
Re: Replacing default work dir from tmp to current dir
+1 for the user.dir as a default one.
Denis
On Monday, August 12, 2019, Dmitriy Pavlov 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 :
>
> > 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 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
Re: Replacing default work dir from tmp to current dir
+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 :
> 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 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
> > >>
> >
> >
> >
>
Re: Replacing default work dir from tmp to current dir
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 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
> >>
>
>
>
Re: Replacing default work dir from tmp to current dir
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 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
>>
Re: Replacing default work dir from tmp to current dir
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
