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 <[email protected]> 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 <[email protected]> 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 > >
