Hi Maxim, > On the other hand, I don't see any valuable reason why the change can't be done and we should wait for the future that never comes. Maxim, the community must provide a reasonable time interval in order to notify all contributors and wait for updating all 3-rd party plugins. Honestly, it does not seem to me that two, three months (the current timeline - end of March is the release date, so the end of Feb is code freeze) are quite enough.
> I don't see any reasons why we should keep something in the CORE module that is being used at PLUGINS only. This is a lack of architecture design that must be fixed for sure; I agree with you. We just need to provide a window that is enough to cover all related issues. For example, distributed meta storage does not provide the ability to atomically change several properties at the same time (there are no transactions on this API). Perhaps, it would be nice to plan to remove the system cache on 2.14 or even 2.15. What do you think? Thanks, S. вт, 30 нояб. 2021 г. в 13:58, Maxim Muzafarov <mmu...@apache.org>: > Hello Val, > > Thank you for sharing the details. On the one hand, I agree with you > that there is no need to haste with this change and it must be > prepared carefully. On the other hand, I don't see any valuable reason > why the change can't be done and we should wait for the future that > never comes. > > Please, consider the following my considerations: > > - The release 2.13 is not started yet. It will take months to be > released (e.g. the end of March as a possible release date). The time > is more than enough; > - The 2.13 release has breaking changes, so it is a good opportunity > to fix some gaps; > - I don't see any reasons why we should keep something in the CORE > module that is being used at PLUGINS only. This is a lack of > architecture design that must be fixed for sure; > - The cache affects cluster stability and require additional human > resources for the code maintenance; > - As a straightforward solution plugins can create their own internal > caches and use them ever they like (or use the metastorage as I > mentioned earlier). Moving system cache to plugin doesn't look so > complicated and harmful; > > On Mon, 29 Nov 2021 at 23:07, Valentin Kulichenko > <valentin.kuliche...@gmail.com> wrote: > > > > Maxim, > > > > You're right that the system cache is still likely to be used by plugins. > > We at GridGain use it for security features, for example. As far as I > know, > > that's not the only case. > > > > I also agree that the metastorage should be the preferred way for this > kind > > of purposes, but is there any harm in keeping the system cache for now? > > Unlike the legacy Service Grid, this is not a public feature that can be > > used directly by a regular user, so I'm not sure why the rush. > > > > How about we instead deprecate the system cache, clearly document how to > > use the metastorage as an alternative, and then complete the removal > > sometime in the future? > > > > -Val > > > > On Sun, Nov 28, 2021 at 6:49 AM Maxim Muzafarov <mmu...@apache.org> > wrote: > > > > > Igniters, > > > > > > > > > Since the legacy service grid implementation was removed [2] I'd like > > > to remove the ignite-sys-cache also. It is still possible that some of > > > Ignite plugins (e.g. security plugin) are still using this cache, > > > however, AFAIK this is not the reason to keep the outdated system > > > cache and these plugins must be migrated to the metastorage instead. > > > > > > I've filed the issue [1] for removal. Any objections? > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16008 > > > [2] https://issues.apache.org/jira/browse/IGNITE-15758 > > > >
