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,
signature.asc
Description: This is a digitally signed message part
