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 <nizhi...@apache.org>: > 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, >
