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
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
>
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
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
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
> 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
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
>
> 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.
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,
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
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
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
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
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
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
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
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
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
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
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
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
>
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 авг.
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,
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
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
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
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
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
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,
/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
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
+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/
>
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
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
>
>
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,
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
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
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
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:
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
+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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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,
+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
+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
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
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
>
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,
61 matches
Mail list logo
