Sergey, I think the ticket covers single atomic piece of functionality.
I'd prefer to avoid to separately address flaws in current service upgrade process because this process had never been designed, implemented and supported. Yes, in current ServiceGrid implementation you can (technically) replace existing service with newer implementation, and there are a number of potential problems you might encounter while doing so. But it doesn't make much sense to me to fix flaws in functionality that officially doesn't exist. Those issues should be addressed in the scope of service versioning. Use-cases that you described are interesting and we should try to support them, but I don't think that we should implement functionality for all possible cases in single step. I'll think how we can technically support them in Ignite and I'm open to suggestions from you (and anyone else). I don't think I understand your concept of ServiceRegistry in the same way you do. Could you please describe it in more detail? Thanks. On Wed, Aug 16, 2017 at 6:06 PM, Sergey Chugunov <sergey.chugu...@gmail.com> wrote: > Ilya, > > I think the proposed change definitely makes sense. > > At the same time I think the scope of the ticket is too broad. It covers at > least two different aspects of service grid functionality: > > - Very specific issue of service upgrade process which is caused by > current design flaw (although it's not a bug). > - Very high-level suggestions about improving upgrade process in > general. > > > I think it is better to separate these things. Lets firstly address item#1 > and then reiterate on #2. > > Managing services deployment in distributed system is a non-trivial task > with a lot of options and different requirements; all changes and > improvements must be designed thoughtfully. > > E.g. for the requirement from the ticket that all services under the same > name must be of the same version: what if a user wants to test a new > implementation transparently to the clients of the cluster? > It would be convenient for that user to be able to redeploy only one > instance of the service to the newer version (without touching other > instances) and see if any client reports a problem. > > Also I'm familiar with an example when a system with service-like entities > connected to it supported both upgrades and downgrades: it was possible to > connect new versions of services to the "parent" system, send some work to > them but in case of any issues with newer version it was always possible to > quickly fall back to the previous one known to be stable. > This use case isn't covered in your ticket at all although I think it is > kind of obvious feature. > > From my point of view Ignite just doesn't have necessary internal > abstractions to support rich service functionality with managing versions, > upgrades/downgrades and so on. > Something like distributed ServiceRegistry concept with managing API to the > user. We don't have anything like this now. > > So I think we should focus on addressing existing issue described in item#1 > and start a new discussion about ways to improve our service grid > capabilities in a separate thread. > Item#2 will be addressed automatically as part of that discussion. > > Makes sense? > > Thanks, > Sergey. > > On Wed, Aug 16, 2017 at 2:22 AM, Denis Magda <dma...@apache.org> wrote: > > > Ilya, > > > > Every Service Grid user will welcome this feature. Fully for it. > > > > Mentioned in the ticket that it has to be documented before the ticket is > > closed. > > > > — > > Denis > > > > > On Aug 15, 2017, at 8:18 AM, Ilya Lantukh <ilant...@gridgain.com> > wrote: > > > > > > Igniters, > > > > > > Our current ServiceGrid implementation lacks several important > features, > > > one of which is ability to upgrade Service without downtime. > > > > > > I've created ticket to add this feature: > > > https://issues.apache.org/jira/browse/IGNITE-6069. > > > > > > To implement it, the following problems must be solved: > > > - currently we can store only one BinaryMetadata instance for given > > > classname - if you change Service class implementation and then try to > > > deploy it, you might get an exception like > > > "org.apache.ignite.binary.BinaryObjectException: Binary type has > > different > > > field types". It can be solved by making (className, version) unique > > > metadata identifier. We can use serialVersionUuid as version. > > > - ServiceProxy must be aware of actual version and know if service is > > > currently being upgraded. If user tries to execute any method during > > > upgrade, proxy should implicitly wait until new version is ready. We > > > already have similar logic in IgniteCacheProxyImpl. > > > - To effectively and conveniently migrate service state to newer > version, > > > we should add method to Service interface that will be executed before > > > start if older version was present. To keep API compatible, I suggest > to > > > introduce interface UpgradableService (extends Service). > > > > > > Any critique and suggestions are welcome. > > > > > > -- > > > Best regards, > > > Ilya > > > > > -- Best regards, Ilya
