Val, The plan should be more precise. So at the very high level:
1. Deprecate the system cache in 2.13. 2. Remove the system cache in 2.14. 2.14 should happen in the mid of the next year I suppose. I don't think we should write guides for the system cache > metastorage migration process. This is a completely internal API and we can change it. Any plugin can create its own internal cache for any needs and if there are any hooks required for it (e.g. like PartitionsExchangeAware interface) it might be added prior to the removal. After we agreed on this plan we can send a notification for dev, user lists about these changes, so all the plugin developers will be up to date. But I think that everyone has already known everything, so let's move on :-) On Mon, 6 Dec 2021 at 20:22, Nikolay Izhikov <nizhi...@apache.org> wrote: > > Valentin, > > > However, changes like system cache removal are much more critical, because > > a plugin might rely on it. > > I’m still don’t understand - what is the difference between system cache and > any other Ignite cache except the name? > Do we have some special guarantees for system cache? > > > Any objections to the plan I've suggested earlier? > > 1. Write down the differences between the system cache and the metastorage, > > and provide a transition guide for plugin developers. > > Don’t think we need any transition guide. > > > I don't think it's reasonable to do this earlier than mid next year > > This date are questionable, also. > > Other points of your plan makes sense. > +1 to follow it. > > > 6 дек. 2021 г., в 20:16, Valentin Kulichenko > > <valentin.kuliche...@gmail.com> написал(а): > > > > That's correct. > > > > Folks, can we agree on how we want to approach the removal of the system > > cache? Any objections to the plan I've suggested earlier? As a reminder, > > here it is: > > 1. Write down the differences between the system cache and the metastorage, > > and provide a transition guide for plugin developers. > > 2. Deprecate the system cache in 2.13. > > 3. Remove the system cache in one of the further releases. I don't think > > it's reasonable to do this earlier than mid next year (even that is > > potentially too early). > > > > As for general compatibility requirements related to plugins, I think they > > obviously should not be as strict as for the public API. It's > > understandable that a method signature can be updated, or another similar > > change can be made in internal APIs. However, changes like system cache > > removal are much more critical, because a plugin might rely on it. It's our > > responsibility as a good friendly community to provide a reasonable > > alternative and a reasonable timeline for such a case. > > > > -Val > > > > On Mon, Dec 6, 2021 at 8:56 AM Вячеслав Коптилин <slava.kopti...@gmail.com> > > wrote: > > > >> Hi, > >> > >>> Plugins have access to different internal Ignite components, such as > >> security processor and others, and can extend the programmatic API of > >> Ignite. > >> > >>> Where docs say that we, as a community, take responsibility to keep > >> internals in the way plugin expect? > >> Nikolay, it seems to me, that quoted text clearly states about that. > >> Plugin has access to internal APIs and so it depends on it. If we want to > >> be a friendly community then we should discuss such changes > >> (removing/changing internal APIs) and provide a reasonable time in order to > >> update such dependencies. > >> > >> I think no one in this topic is against removing sys-cache. The question > >> is: is it suitable for the community to deprecate using system cache in > >> 2.13 and removing it in 2.14 || 2.15? > >> Am I missing something? Am I correct? > >> > >> Thanks, > >> Slava. > >> > >> > >> пн, 6 дек. 2021 г. в 15:00, Nikolay Izhikov <nizhi...@apache.org>: > >> > >>> Slava, I don’t get it. > >>> > >>>> Plugins have access to different internal Ignite components, such as > >>> security processor and others, and can extend the programmatic API of > >>> Ignite. > >>> > >>> Where docs say that we, as a community, take responsibility to keep > >>> internals in the way plugin expect? > >>> > >>>> 6 дек. 2021 г., в 14:48, Вячеслав Коптилин <slava.kopti...@gmail.com> > >>> написал(а): > >>>> > >>>> Hello Nikolay, > >>>> > >>>>>> plugin framework allows to implement internal components and use the > >>>> internal API. > >>>>> Can you please, point out to documentation or place in Ignite code > >> that > >>>> describe this behaviour? > >>>> > >>>> Looks like it states here > >> https://ignite.apache.org/docs/latest/plugins > >>>> > >>>>> The Ignite plugin system allows you to extend the core functionality > >> of > >>>>> Ignite. Plugins have access to different internal Ignite components, > >>> such > >>>>> as security processor and others, and can extend the programmatic API > >> of > >>>>> Ignite. > >>>> > >>>> > >>>> Thanks, > >>>> S. > >>>> > >>>> > >>>> сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov <nizhi...@apache.org>: > >>>> > >>>>> Valentin > >>>>> > >>>>>> plugin framework allows to implement internal components and use the > >>>>> internal API. > >>>>> > >>>>> Can you please, point out to documentation or place in Ignite code > >> that > >>>>> describe this behaviour? > >>>>> AFAIK plugin can only use public API, internal API can be changed any > >>> time > >>>>> we want. > >>>>> > >>>>>> Folks, can anyone explain the rush? > >>>>> > >>>>> No rush from my side. > >>>>> > >>>>> Just want to understand your vision of integration points between > >> Ignite > >>>>> and plugins. > >>>>> > >>>>>> Is there any specific reason for it? > >>>>> > >>>>> Intention of IEP-80 is to improve Ignite codebase by removing > >> abandoned > >>>>> features. > >>>>> > >>>>>> But the fact is that there are users that can depend on the system > >>> cache > >>>>> via the plugin framework. > >>>>> > >>>>> Why this dependency can’t be changed to any regular cache? > >>>>> Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s > >> it. > >>>>> > >>>>> Do we have some special guarantees or logic besides system cache? > >>>>> > >>>>> > >>>>>> 4 дек. 2021 г., в 02:14, Valentin Kulichenko < > >>>>> valentin.kuliche...@gmail.com> написал(а): > >>>>>> > >>>>>> Nikolay, that's right, plugin framework allows to implement internal > >>>>>> components and use the internal API. There is a difference between a > >>>>> plugin > >>>>>> and an extension that uses only public API > >>>>>> > >>>>>> Folks, can anyone explain the rush? Is there any specific reason for > >>> it? > >>>>>> > >>>>>> I think we all agree that this is a good change - system cache has to > >>>>> go. I > >>>>>> guess technically it's not even a breaking change, because system > >> cache > >>>>> is > >>>>>> not a public API feature. But the fact is that there are users that > >> can > >>>>>> depend on the system cache via the plugin framework. Let's be > >>> respectful > >>>>> to > >>>>>> those users, provide a reasonable documented alternative and give > >> time. > >>>>>> > >>>>>> -Val > >>>>>> > >>>>>> On Fri, Dec 3, 2021 at 8:18 AM Nikolay Izhikov <nizhi...@apache.org> > >>>>> wrote: > >>>>>> > >>>>>>> I don’t understand how it possible. > >>>>>>> > >>>>>>> Are you talking about plugin that uses some kind of internal API? > >>>>>>> > >>>>>>>> 3 дек. 2021 г., в 18:50, Вячеслав Коптилин < > >> slava.kopti...@gmail.com > >>>> > >>>>>>> написал(а): > >>>>>>>> > >>>>>>>> Hello Nikolay, > >>>>>>>> > >>>>>>>> If I am not mistaken, the method you mentioned, allows to create a > >>>>> "user" > >>>>>>>> cache that is available through public api for the user. This does > >>> not > >>>>>>>> cover the case when the plugin developer wants to hide such cache > >> and > >>>>>>>> protect it form the end user (at least, via public api). > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> S. > >>>>>>>> > >>>>>>>> пт, 3 дек. 2021 г., 14:15 Nikolay Izhikov <nizhi...@apache.org>: > >>>>>>>> > >>>>>>>>> Vyacheslav, Val, can you please clarify - What is the issue if > >>>>>>> third-party > >>>>>>>>> plugins will create «ignite-sys-cache» from the code? > >>>>>>>>> > >>>>>>>>> Like just replacing `Ignite#cache` with the > >>> `Ignite#getOrCreateCache`. > >>>>>>>>> > >>>>>>>>>> 2 дек. 2021 г., в 16:13, Вячеслав Коптилин < > >>> slava.kopti...@gmail.com > >>>>>> > >>>>>>>>> написал(а): > >>>>>>>>>> > >>>>>>>>>> Hello Maxim, > >>>>>>>>>> > >>>>>>>>>>> I don't understand why you are using *backwards compatibility* > >> for > >>>>>>>>>> completely internal things. > >>>>>>>>>>> Why you are thinking in terms of users usage when are talking > >>> about > >>>>>>>>>> ignite-sys-cache but not thinking when refactoring > >>>>>>>>>> First of all, we are talking about all plugin developers. It does > >>> not > >>>>>>>>>> matter it is open-source or proprietary plugins. > >>>>>>>>>> Honestly, I don't have a list of all possible plugins that have > >>>>> already > >>>>>>>>>> been developed and available under the ASF license, for instance. > >>>>>>>>>> Do you have such a list? Can you be sure that this change will > >> not > >>>>>>> affect > >>>>>>>>>> anyone? > >>>>>>>>>> > >>>>>>>>>>> I don't understand why you are using *backwards compatibility* > >> for > >>>>>>>>>> completely internal things. > >>>>>>>>>>> Why you are thinking in terms of users usage when are talking > >>> about > >>>>>>>>>> ignite-sys-cache but not thinking when refactoring > >>>>>>>>>> The system cache was the crucial thing in the architecture of > >>> Apache > >>>>>>>>> Ignite > >>>>>>>>>> 1.x and 2.x (at least 2.1 - 2.11?) > >>>>>>>>>> > >>>>>>>>>>> All the internals have been reworked and nobody even mentioned > >>> that > >>>>> it > >>>>>>>>>> may affect some of the plugin developers. > >>>>>>>>>> Yep, perhaps, some internal parts of Apache Ignite were reworked > >> in > >>>>>>> order > >>>>>>>>>> to avoid using the system cache. > >>>>>>>>>> However, it is still a part of Ignite and it works and can be > >> used > >>> in > >>>>>>>>>> plugins. > >>>>>>>>>> Honestly, the mentioned alternative, I mean the distributed > >>>>>>> metastorage, > >>>>>>>>> is > >>>>>>>>>> the INTERNAL thing as well. > >>>>>>>>>> It means that plugin developer depends on INTERNAL entities. (it > >>> does > >>>>>>> not > >>>>>>>>>> matter system-cache/metastorage) > >>>>>>>>>> IMHO, such questions should be CAREFULLY discussed with no rush. > >>>>>>>>>> > >>>>>>>>>>> I do not propose to rush with the ignite-sys-cache removal. I'd > >>> like > >>>>>>> to > >>>>>>>>>> collect all the technical stuff that we depend on, fix all of > >> them > >>>>> and > >>>>>>>>>> after everything will be ready do a final removal. > >>>>>>>>>> Good! We are on the same page! > >>>>>>>>>> > >>>>>>>>>>> 1. Add deprecation for the 2.12 release. I hope it is still > >>>>> possible. > >>>>>>>>>> If I am not mistaken, the code freeze was October 29. I think it > >> is > >>>>> too > >>>>>>>>>> late to introduce this change. We can add deprecation for the > >> 2.13 > >>>>>>>>> release. > >>>>>>>>>> > >>>>>>>>>>> Apache Ignite core still have some dependencies on > >>> ignite-sys-cache > >>>>>>> that > >>>>>>>>>> should fix for 2.13 > >>>>>>>>>> Ok, I agree. We need to try to find out all edge cases and add > >> new > >>>>>>>>>> abilities to the metastorage in order to cover all known > >>>>>>>>>> issues/requirements. > >>>>>>>>>> > >>>>>>>>>>> Remove the system cache in 2.14. > >>>>>>>>>> It depends on our progress with improving the distributed > >>>>> metastorage. > >>>>>>> In > >>>>>>>>>> general, I hope it will be possible. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> S. > >>>>>>>>>> > >>>>>>>>>> чт, 2 дек. 2021 г. в 13:36, Maxim Muzafarov <mmu...@apache.org>: > >>>>>>>>>> > >>>>>>>>>>> Pavel, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I don't understand why you are using *backwards compatibility* > >> for > >>>>>>>>>>> completely internal things. Why you are thinking in terms of > >> users > >>>>>>>>>>> usage when are talking about ignite-sys-cache but not thinking > >>> when > >>>>>>>>>>> refactoring, for instance, all the checkpoint classes? Take a > >> look > >>>>> at > >>>>>>>>>>> the [1] issue. All the internals have been reworked and nobody > >>> even > >>>>>>>>>>> mentioned that it may affect some of the plugin developers. This > >>> is > >>>>>>>>>>> really strange, so I can't agree with you. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I do not propose to rush with the ignite-sys-cache removal. I'd > >>> like > >>>>>>>>>>> to collect all the technical stuff that we depend on, fix all of > >>>>> them > >>>>>>>>>>> and after everything will be ready do a final removal. Slava > >>> already > >>>>>>>>>>> mentioned some crucial cases, so I hope you and Val also help > >> with > >>>>> the > >>>>>>>>>>> rest of them. Let's be more precise in terms *what we need to > >>> fix*. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I've made some investigations related to the ignite-sys-cache > >> and > >>>>> here > >>>>>>>>>>> is my proposal: > >>>>>>>>>>> > >>>>>>>>>>> 1. Add deprecation for the 2.12 release. I hope it is still > >>>>> possible. > >>>>>>>>>>> > >>>>>>>>>>> 2. Apache Ignite core still have some dependencies on > >>>>> ignite-sys-cache > >>>>>>>>>>> that should fix for 2.13: > >>>>>>>>>>> > >>>>>>>>>>> 2.1. CLUSTER_NAME property: when it's not set the `deploymentId` > >>> of > >>>>>>>>>>> system cache is used. Let's move it to metastorage. > >>>>>>>>>>> 2.2. When the Security is enabled each compute task name (hash > >> to > >>> be > >>>>>>>>>>> more precise) is written to the ignite-sys-cache [2]. From my > >>> point > >>>>> of > >>>>>>>>>>> view, we can remove it in 2.13. Can anyone check? > >>>>>>>>>>> 2.3. Slava mentioned some issues with the distributed > >> metastorage > >>>>> that > >>>>>>>>>>> might be fixed. I think this is doable. > >>>>>>>>>>> > >>>>>>>>>>> 3. Remove the system cache in 2.14. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-13143 > >>>>>>>>>>> [2] > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >>> > >> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskProcessor.java#L201 > >>>>>>>>>>> > >>>>>>>>>>> On Thu, 2 Dec 2021 at 12:56, Pavel Tupitsyn < > >> ptupit...@apache.org > >>>> > >>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Maxim, > >>>>>>>>>>>> > >>>>>>>>>>>>> I don't think that we should wait for 3-rd party plugins to be > >>>>>>> updated > >>>>>>>>>>>>> this is an awful practice when the open-source product > >> releases > >>>>>>> depend > >>>>>>>>>>>>> on some of the proprietary plugins > >>>>>>>>>>>> > >>>>>>>>>>>> This makes no sense, sorry. > >>>>>>>>>>>> > >>>>>>>>>>>> It is not that we depend on 3rd party plugins. > >>>>>>>>>>>> It is that *our users depend on us to preserve backwards > >>>>>>>>> compatibility*. > >>>>>>>>>>>> No one likes when their app breaks suddenly because of a > >> library > >>>>>>>>> update. > >>>>>>>>>>>> > >>>>>>>>>>>> We know about one use case for sys-cache in GridGain, but there > >>> may > >>>>>>> be > >>>>>>>>>>>> more, no one knows. > >>>>>>>>>>>> Every breaking change should be carried out carefully and > >>>>> gradually. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Dec 2, 2021 at 12:34 PM Maxim Muzafarov < > >>> mmu...@apache.org > >>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Slava, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thank you for the comments. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Maxim, the community must provide a reasonable time interval > >> in > >>>>>>>>>>> order to > >>>>>>>>>>>>> notify all contributors and wait for updating all 3-rd party > >>>>>>> plugins. > >>>>>>>>>>>>> > >>>>>>>>>>>>> This is not actually true. We must notify about changes as > >>> earlier > >>>>>>> as > >>>>>>>>>>>>> possible and not only users but all the developers also. > >>> However, > >>>>> I > >>>>>>>>>>>>> don't think that we should wait for 3-rd party plugins to be > >>>>> updated > >>>>>>>>>>>>> this is an awful practice when the open-source product > >> releases > >>>>>>> depend > >>>>>>>>>>>>> on some of the proprietary plugins. There is no dependency > >>> between > >>>>>>>>>>>>> Apache Ignite releases and proprietary plugin releases. If > >>> someone > >>>>>>>>>>>>> desires to upgrade to a new version of Apache Ignite it can > >>> update > >>>>>>> its > >>>>>>>>>>>>> plugins any time he likes. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> We just need to provide a window that is enough to cover all > >>>>>>> related > >>>>>>>>>>>>> issues. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Can you share all the issues you know, please? > >>>>>>>>>>>>> > >>>>>>>>>>>>>> distributed meta storage does not provide the ability to > >>>>> atomically > >>>>>>>>>>>>> change several properties at the same time (there are no > >>>>>>> transactions > >>>>>>>>>>> on > >>>>>>>>>>>>> this API). > >>>>>>>>>>>>> > >>>>>>>>>>>>> Can you share an example of what kind of properties we intend > >> to > >>>>>>>>>>>>> change at the same? Will it be enough to change them through a > >>>>>>> single > >>>>>>>>>>>>> thread (e.g. the discovery thread or the exchange thread)? I > >>> agree > >>>>>>>>>>>>> here that distributed metastorage should provide such an > >>> ability, > >>>>>>>>>>>>> however, I can't find any real examples for Apache Ignite > >>> internal > >>>>>>>>>>>>> needs. Please, share the details and let's fix it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Wed, 1 Dec 2021 at 23:19, Valentin Kulichenko > >>>>>>>>>>>>> <valentin.kuliche...@gmail.com> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Agree with Slava. Two months is not enough time, especially > >>>>>>>>>>> considering > >>>>>>>>>>>>>> that the system cache is not functionally equivalent to the > >>>>>>>>>>> metastorage. > >>>>>>>>>>>>> I > >>>>>>>>>>>>>> suggest we do the following: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1. Write down the differences between the system cache and > >> the > >>>>>>>>>>>>> metastorage, > >>>>>>>>>>>>>> and provide a transition guide for plugin developers. > >>>>>>>>>>>>>> 2. Deprecate the system cache in 2.13. > >>>>>>>>>>>>>> 3. Remove the system cache in one of the further releases. I > >>>>> don't > >>>>>>>>>>> think > >>>>>>>>>>>>>> it's reasonable to do this earlier than mid next year (even > >>> that > >>>>> is > >>>>>>>>>>>>>> potentially too early). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Removing the system cache is the right move, but let's be > >> more > >>>>>>>>>>>>> considerate > >>>>>>>>>>>>>> to the users. There is absolutely no need to rush. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -Val > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Dec 1, 2021 at 7:28 AM Вячеслав Коптилин < > >>>>>>>>>>>>> slava.kopti...@gmail.com> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> > >>> > >> >
