Mailing-List: contact dev-help@ariatosca.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ariatosca.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMeryBe5FC+-VV4hL+HOUG6Qi_N0mr5mbuAHsB-QXJ52Tiom8w@mail.gmail.com>
References: <CAJm-Kz3Whr0Kf=nFkMhhY4WJnKM_rNOUdEMPz2jqUvyg4J7egw@mail.gmail.com>
 <CAMeryBfpA4DHAyQWe_PR66E3QX6LBTgNLcc7Xh=-JXNv=uC8gw@mail.gmail.com>
 <CAFCKrYj4eG3bdzusQTz-TuYDrZB7A1riy4uEv0exOsM=+GrJnA@mail.gmail.com>
 <CAMeryBd4=WFpA4jkF_wzpsDuF-CNqo8gS-VXak7JnzDFR77rcw@mail.gmail.com>
 <CAFCKrYgCfKnC1jRgMPL4Ty69ZhXKxAJhzKSgTdLEiyDUvhwVqg@mail.gmail.com> <CAMeryBe5FC+-VV4hL+HOUG6Qi_N0mr5mbuAHsB-QXJ52Tiom8w@mail.gmail.com>
From: Ran Ziv <ran@cloudify.co>
Date: Tue, 8 Aug 2017 02:42:08 +0300
Message-ID: <CAAduSmN9qYFcYRfZX7nbCVzsrciLSwC0EfSwVCyBY9wNifMQyA@mail.gmail.com>
Subject: Re: Service Composition / Substitution Mapping
To: dev@ariatosca.incubator.apache.org
Content-Type: multipart/alternative; boundary="001a114db990294cac055632659c"
archived-at: Mon, 07 Aug 2017 23:42:26 -0000

--001a114db990294cac055632659c
Content-Type: text/plain; charset="UTF-8"

The sensible defaults Tal's mentioned sound indeed sensible to me.
I'd also like users to have control over this, though I'm a bit worried
about us getting too carried away with how arbitrarily we use policies for
configuring, well, pretty much anything. It might not be a problem right
now but I'm not certain that will remain the case in the future when the
number of them grows..


On Wed, Aug 2, 2017 at 7:14 PM, Tal Liron <tal@cloudify.co> wrote:

> Our goal with adding new "conventions" to ARIA, such as policies, is to
> always make them optional. The idea is that a plain-vanilla TOSCA template
> would "just work" in ARIA via sensible defaults. The extra stuff is there
> if you know you are using ARIA and you want to make use of its features.
> (The opposite is true, too: we make sure that any additions are still pure
> TOSCA and would be parsed validly by other TOSCA parsers.)
>
> On Wed, Aug 2, 2017 at 9:08 AM, DeWayne Filppi <dewayne@cloudify.co>
> wrote:
>
> > Cool.  Missed that.  That leaves things almost completely wide open from
> > the orchestrator side, IOW few predefined keys.  Too few IMHO, but if
> > everyone uses ARIA conventions it could work.
> >
> > On Tue, Aug 1, 2017 at 11:49 PM, Tal Liron <tal@cloudify.co> wrote:
> >
> > > I agree! Luckily metadata exists in the 1.0 spec. :)
> > >
> > > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#_
> Toc379455044
> > >
> > > On Tue, Aug 1, 2017 at 7:16 PM, DeWayne Filppi <dewayne@cloudify.co>
> > > wrote:
> > >
> > > > It occurs that it might be useful to be able to tag service templates
> > > with
> > > > arbitrary meta-data.  Perhaps at one level carried forward from a
> CSAR
> > > > manifest, but also user definable.  This would allow inter-service
> > > > references to be definitive, if desired.  This could be implicitly
> > > defined
> > > > as a capability by the orchestrator, but some kind of special
> > requirement
> > > > type(s) would be needed to utilize it.  This way, external repos
> could
> > be
> > > > used safely and directly without the separate load step.
> > > >
> > > > On Tue, Aug 1, 2017 at 12:43 PM, Tal Liron <tal@cloudify.co> wrote:
> > > >
> > > > > Thanks for the kudos. :)
> > > > >
> > > > > This topic was discussed on this list a while ago. It's indeed
> tricky
> > > to
> > > > > get right, because TOSCA leaves a lot of room for the orchestrator
> to
> > > > > implement.
> > > > >
> > > > > I'm thinking of it working something like this:
> > > > >
> > > > > 1. The reqs-and-caps engine by default will always look for
> > satisfiable
> > > > > capabilities within the currently instantiated service. HOWEVER, if
> > > such
> > > > a
> > > > > capability is not present, the option is there to look for another
> > > > > instantiated service that exposes the capabilities in substitution
> > > > > mappings.
> > > > >
> > > > > 2. If we DON'T have another instantiated service, but DO have a
> > service
> > > > > template that could fit the bill, perhaps we need to instantiate
> that
> > > > other
> > > > > service first. One obvious option is to do this automatically. But
> I
> > > feel
> > > > > like this can create unforeseen consequences -- for example, some
> > dummy
> > > > > test template that someone happened to have in the database might
> get
> > > > > instantiated by mistake. Also, it might need to trigger multiple
> > > install
> > > > > workflows at once... a big mess. So I suggest that instead we
> > provide a
> > > > > very detailed validation error here saying that the requirement
> > cannot
> > > be
> > > > > satisfied, HOWEVER there exist service templates A, B, and C that
> can
> > > > > substitute for us, so maybe the nice user would like to instantiate
> > > them
> > > > > first? This seems very reasonable to me.
> > > > >
> > > > > 3. If indeed another service satisfies this, a special node is
> added
> > to
> > > > the
> > > > > current service (with the correct type -- but without a service
> > > template
> > > > > foreign key), which serves as a proxy of the other service
> template.
> > > I'm
> > > > > not sure how we would mark this exactly. We can't use the
> service_fk
> > > > field,
> > > > > because it's still in our current service. So perhaps there's need
> > of a
> > > > new
> > > > > fk field, maybe substituted_service_fk?
> > > > >
> > > > > The above might be "sensible defaults," but it seems to me that
> users
> > > > > really need control over this. So I propose to add a new
> > > aria.Composition
> > > > > policy that would let you provide hints for this mechanism. For
> > > example,
> > > > > you might want to "filter" the target service by service template
> > name
> > > > and
> > > > > even by metadata in the service template. For example, you might
> want
> > > to
> > > > > require version 1.2.2 of a specific service, no less.
> > > > >
> > > > > Those are some quick thoughts. Exactly how such a policy would look
> > > with
> > > > > require more thought...
> > > > >
> > > > >
> > > > > On Tue, Aug 1, 2017 at 2:20 PM, Avia Efrat <avia@cloudify.co>
> wrote:
> > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > I'm starting to work on a full implementation of
> > > substitution_mapping,
> > > > > > which will lead to the ability of service composition.
> > > > > >
> > > > > > For those unacquainted with substitution mapping, here are some
> > quick
> > > > > > resources:
> > > > > > *From the spec
> > > > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > > > YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html>,
> > > > > > sections:*
> > > > > > 2.10
> > > > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_
> > Toc471725208>,
> > > > > > 2.11
> > > > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_
> Toc471725209>
> > > > > > (theory and examples)
> > > > > > 3.8.1, 3.8.2 (grammar)
> > > > > > *From Tal's amazing lecture on TOSCA
> > > > > > <https://www.youtube.com/watch?v=6xGmpi--7-A>:*
> > > > > > 00:00 until 12:30.
> > > > > >
> > > > > > If anyone wishes to:
> > > > > > * ask questions regarding this feature
> > > > > > * suggest real-life use cases
> > > > > > * offer their insight about vague parts of the spec
> > > > > > * anything else about substitution mapping and service
> composition
> > > > > > Then please, feel encouraged to leave your feedback!
> > > > > >
> > > > >
> > > >
> > >
> >
>

--001a114db990294cac055632659c--