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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >>
