Hello, Igniters.
I am working on task [1] that would replace serialized service's instance
by service's class name and properties map in {ServiceConfiguration}.
The task describes that we should use
{String className} + {Map<String, Object> properties} instead {Service
srvc}.
I'd like to clarify the following questions:
1. What about public methods?
I suggest to mark them as deprecated and use class name of provided
instance.
Also to add deploying methods with new parameters:
@Deprecated
public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj, String
name, Service svc)
public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj, String
name, String srvcClsName, Map<String, Object> prop)
2. Is {Map<String, Object> properties} parameter mandatory when deploying a
service?
Is it make sense to add deploying methods without it? For example:
public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj, String
name, String srvcClsName)
public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj, String
name, String srvcClsName, Map<String, Object> prop)
Thoughts?
1. https://issues.apache.org/jira/browse/IGNITE-8366
2018-08-09 18:21 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> 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.
> > > >
> > >
> >
>
--
Best wishes,
Amelchev Nikita
