Vyacheslav, For the case you are describing, I would take the same approach as we have for compute tasks. Keep the older version around only as long as there are active requests and then undeploy it automatically. No need to allow it linger around indefinitely.
D. On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur <daradu...@gmail.com> wrote: > Dmitry, it's not only about hot redeployment. > > Denis, I don't see such use case, because of the answer in a different > front. > > It relates to the best practices of SOA versioning [1] [2]. > > For example: > * we have a cluster with service [name="MySevice", v="1"]; > * I want to upgrade service to [name="MySevice", v="2"], but I have > clients which are using [name="MySevice", v="1"] and can't stop > processing; > * With service versioning, we are able to deploy new service near > existing service, then switch clients and undeploy outdated service. > > My only question is: are we going to implement such a feature [3] or > not? Maybe PMC don't see such feature in Service Grid roadmap. > IMO it's a good feature for a microservices platform. > > > [1] https://www.thbs.com/thbs-insights/soa-service- > versioning-best-practices > [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly- > developing-applications-part-6-exposing-and-versioning-apis/ > [3] https://issues.apache.org/jira/browse/IGNITE-6069 > On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > > Guys, > > > > I thought this was about automatic service redeployment, which should > have > > been a part of the current IEP, no? Can you please clarify? > > > > D. > > > > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <dmekhani...@gmail.com> > > wrote: > > > > > Vyacheslav, > > > > > > It looks like an overcomplication to me. > > > Could you describe a case, that can be solved using versioning, but not > > > naming? > > > > > > Denis > > > > > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <daradu...@gmail.com>: > > > > > > > Denis, it's not about different users services implementations. > > > > > > > > A real use case is user's services API versioning which is being used > > > > widely t in SOAP/REST microservices infrastructure. > > > > > > > > In my opinion, it is about services with the same name and the same > > > > full class name, but different classes versions for example in > > > > different classloaders. > > > > > > > > > > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov < > dmekhani...@gmail.com> > > > > wrote: > > > > > > > > > > I don't think, that we really need this feature. > > > > > It seems to me, that if you want to use a different implementation > of a > > > > > service, you can assign a different name to it. > > > > > > > > > > What do you think? > > > > > > > > > > Denis > > > > > > > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan < > dsetrak...@apache.org>: > > > > > > > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur < > > > > daradu...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hi, Igniters! > > > > > > > > > > > > > > I found a ticket about a service’s versioning [1]. > > > > > > > > > > > > > > It’s out of scope IEP-17, but if we are going to implement this > > > > > > > feature we should build a base in the first iteration of IEP-17 > > > > > > > because of change messages formats. > > > > > > > > > > > > > > In case of the versioning which assumes that we are able to > host > > > > > > > services with the same name, but with different class/version, > we > > > > > > > should introduce *service’s id* to manage service’s lifecycle > > > instead > > > > > > > of service’s name. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > My only concern would be on the usability side. Is user going to > have > > > > to > > > > > > deal with IDs now, or will it be handled internally? > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best Regards, Vyacheslav D. > > > > > > > > > > > -- > Best Regards, Vyacheslav D. >
