Re: [DISCUSSION] Remove outdated ignite-sys-cache
Hello Maxim, 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. > I still think that we should not be stuck to a concrete version 2.14. The system cache should be removed when all related improvements will be done (at least, transaction support on the distributed metastorage). Thanks, S. пн, 6 дек. 2021 г. в 20:40, Maxim Muzafarov : > 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 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 : > > >> > > >>> 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 > >
Apache Ignite Contributing
Hello, my name is Andrey Belyaev. I want to contribute to the project. Could you please give me permissions for contributing (login: andreybell) -- С уважением, Беляев Андрей
A new feedback has been added : 37
A new feedback has been added, go to bugyard.io to see all the details... https://bugyard.io A new feedback has been added "Seems like this page is missing in 2.11 docs" by igusev View feedback https://app.bugyard.io/web/app/rycqZJDyY/f/61af218ab0c4230014b7f7ad
Apache Ignite Contributing
Hello, my name is Andrey Belyaev. I want to contribute to the project. Could you please give me permissions for contributing (login: andreybell) -- Best regards
Re: Apache Ignite Contributing
Hello Andrey, I've added you to the Contributors group in JIRA. Welcome to the Apache Ignite community! Pavel On Tue, Dec 7, 2021 at 12:55 PM Андрей Беляев wrote: > Hello, my name is Andrey Belyaev. I want to contribute to the project. > Could you please give me permissions for contributing (login: andreybell) > > -- > Best regards >
Re: Apache Ignite Contributing
Welcome to the community, Andrey! - Ilya вт, 7 дек. 2021 г. в 21:02, Pavel Tupitsyn : > Hello Andrey, > > I've added you to the Contributors group in JIRA. > Welcome to the Apache Ignite community! > > Pavel > > On Tue, Dec 7, 2021 at 12:55 PM Андрей Беляев > wrote: > > > Hello, my name is Andrey Belyaev. I want to contribute to the project. > > Could you please give me permissions for contributing (login: andreybell) > > > > -- > > Best regards > > >
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Maxim, Mid next year is fine, but it makes more sense to bound it by time rather than a specific version. For example, what if we want to release 2.14 earlier for whatever reason? As for the guide, I obviously can't force anyone, but I still believe it is useful, and I hope someone will pick this up. It's also a good practice to document such changes, even for internal purposes. I would do this myself, but I'm afraid my understanding of the topic is not enough :) I think we are on the same page regarding everything else. -Val On Tue, Dec 7, 2021 at 1:46 AM Вячеслав Коптилин wrote: > Hello Maxim, > > 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. > > > I still think that we should not be stuck to a concrete version 2.14. > The system cache should be removed when all related improvements will be > done (at least, transaction support on the distributed metastorage). > > Thanks, > S. > > пн, 6 дек. 2021 г. в 20:40, Maxim Muzafarov : > > > 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 > 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 fo
