Versions will complicate the implementation and will not be done in 2.7. I would vote for the hot redeployment for now and add versions in 2.8.
D. On Thu, Aug 9, 2018 at 10:06 AM, Anton Vinogradov <a...@apache.org> wrote: > Real case is A/B testing. > When you want to allow new service usage only to 0.1% of users. > And only when you sure it works then replace all v1 with v2. > > So, I vote for versions. > Let's do this in maven way (exact version, range, RELEASE or LATEST) > > чт, 9 авг. 2018 г. в 17:55, Dmitriy Setrakyan <dsetrak...@apache.org>: > > > 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. > > > > > >
