Re: Query related to substitution mapping

[Tal Liron <ta...@gigaspaces.com>]

Your expectations are reasonable: that ARIA would look at all of its
current service instances and try to match reqs-and-caps with substitutions.

However, we are a bit far from implementing this. Currently, ARIA only
knows how to match reqs-and-caps within the service.

Also, this feature has to be planned rather carefully: in some cases the
user will not want such automatic matching to happen with services that
just happen to exist in ARIA's db. I think this a great place to introduce
a new Policy that would allow the user to configure exactly how matching
would happen: should the matching prefer external substitutions over
internal nodes? are there limited to how many could be matched? (like the
"occurrences" definition in Capability) should matching only happen with
services of a certain csar/template? etc.

​We are planning some work ahead to refactor the way we instantiate
services, and I think at least some parts of this feature should be
included in that.

Re: Query related to substitution mapping

[Ran Ziv <ra...@gigaspaces.com>]

No, that should not be the case.
However we do aim for making quicker releases in the future, and this is an
issue that we plan on working on soon.

On Fri, Jun 2, 2017 at 10:02 AM, D Jayachandran <d.jayachandran@ericsson.com
> wrote:

> Hi Ran/Tal,
>
> Thanks for the information. It's good to know you already have this as
> part of your backlog.
> We just need to know if you have plans to include this in your upcoming
> release ?
>
>
> Regards,
> DJ
> -----Original Message-----
> From: Ran Ziv [mailto:ran@gigaspaces.com]
> Sent: Thursday, June 01, 2017 10:01 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query related to substitution mapping
>
> i agree for the most part, although I don't see it as part of the
> instantiation phase refactoring, but rather as a completely separate
> feature which I'd like us to work on in the near future.
>
> On Thu, Jun 1, 2017 at 7:27 PM, Tal Liron <ta...@gigaspaces.com> wrote:
>
> > Your expectations are reasonable: that ARIA would look at all of its
> > current service instances and try to match reqs-and-caps with
> > substitutions.
> >
> > However, we are a bit far from implementing this. Currently, ARIA only
> > knows how to match reqs-and-caps within the service.
> >
> > Also, this feature has to be planned rather carefully: in some cases
> > the user will not want such automatic matching to happen with services
> > that just happen to exist in ARIA's db. I think this a great place to
> > introduce a new Policy that would allow the user to configure exactly
> > how matching would happen: should the matching prefer external
> > substitutions over internal nodes? are there limited to how many could
> > be matched? (like the "occurrences" definition in Capability) should
> > matching only happen with services of a certain csar/template? etc.
> >
> > ​We are planning some work ahead to refactor the way we instantiate
> > services, and I think at least some parts of this feature should be
> > included in that.
> >
>

RE: Query related to substitution mapping

[D Jayachandran <d....@ericsson.com>]

Hi Ran/Tal,

Thanks for the information. It's good to know you already have this as part of your backlog.
We just need to know if you have plans to include this in your upcoming release ?


Regards,
DJ
-----Original Message-----
From: Ran Ziv [mailto:ran@gigaspaces.com] 
Sent: Thursday, June 01, 2017 10:01 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query related to substitution mapping

i agree for the most part, although I don't see it as part of the instantiation phase refactoring, but rather as a completely separate feature which I'd like us to work on in the near future.

On Thu, Jun 1, 2017 at 7:27 PM, Tal Liron <ta...@gigaspaces.com> wrote:

> Your expectations are reasonable: that ARIA would look at all of its 
> current service instances and try to match reqs-and-caps with 
> substitutions.
>
> However, we are a bit far from implementing this. Currently, ARIA only 
> knows how to match reqs-and-caps within the service.
>
> Also, this feature has to be planned rather carefully: in some cases 
> the user will not want such automatic matching to happen with services 
> that just happen to exist in ARIA's db. I think this a great place to 
> introduce a new Policy that would allow the user to configure exactly 
> how matching would happen: should the matching prefer external 
> substitutions over internal nodes? are there limited to how many could 
> be matched? (like the "occurrences" definition in Capability) should 
> matching only happen with services of a certain csar/template? etc.
>
> ​We are planning some work ahead to refactor the way we instantiate 
> services, and I think at least some parts of this feature should be 
> included in that.
>

Re: Query related to substitution mapping

[Ran Ziv <ra...@gigaspaces.com>]

i agree for the most part, although I don't see it as part of the
instantiation phase refactoring, but rather as a completely separate
feature which I'd like us to work on in the near future.

On Thu, Jun 1, 2017 at 7:27 PM, Tal Liron <ta...@gigaspaces.com> wrote:

> Your expectations are reasonable: that ARIA would look at all of its
> current service instances and try to match reqs-and-caps with
> substitutions.
>
> However, we are a bit far from implementing this. Currently, ARIA only
> knows how to match reqs-and-caps within the service.
>
> Also, this feature has to be planned rather carefully: in some cases the
> user will not want such automatic matching to happen with services that
> just happen to exist in ARIA's db. I think this a great place to introduce
> a new Policy that would allow the user to configure exactly how matching
> would happen: should the matching prefer external substitutions over
> internal nodes? are there limited to how many could be matched? (like the
> "occurrences" definition in Capability) should matching only happen with
> services of a certain csar/template? etc.
>
> ​We are planning some work ahead to refactor the way we instantiate
> services, and I think at least some parts of this feature should be
> included in that.
>