Support for extension point during service execution

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

Hi Team,

We are looking at an execution point during a service execution through a plugin. With this the execution will not go through the workflow runner (install/uninstall) defined by the orchestrator but the services instance context object will be provided to the plugin which will take care of the complete service-execution.
This plugin is looked upon as a "service plugin" which will get the entire service model object and will provide the details to the external workflow engine.
We need this feature to enable the execution of workflows which some of our users already have. Please let us know your thoughts on this as we have already started our technical study on this.


Regards,
DJ

Re: Support for extension point during service execution

[Tal Liron <ta...@cloudify.co>]

It seems we have duplicated efforts here. DeWayne has separately created a
REST layer for the ONAP project.

DeWayne, could you provide more details?

On Wed, Nov 29, 2017 at 11:59 PM, D Jayachandran <
d.jayachandran@ericsson.com> wrote:

> Hi Tal,
>
> For our use case we have already built a REST Layer on top of ARIA for
> service-template, services and execution creation/start.
> Now for this particular use-case we were looking if we could take the
> service model object and create a service context object out of it, to be
> provided to the service level plugin.
> I was thinking if we had to do this, can this be included as part of ARIA
> (Atleast creation of service context object)
>
> Regards,
> DJ
> -----Original Message-----
> From: Tal Liron [mailto:tal@cloudify.co]
> Sent: Wednesday, November 29, 2017 1:46 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for extension point during service execution
>
> We half do. :) Actually, this has become a major topic of discussion
> recently on other lists. There's some room to discuss exactly what and how
> is available to the ctx proxy. Right now it's both too unrestricted and too
> narrow. The current idea is to make the exposure more explicit, and
> possibly align it with a more general REST API.
>
> On Wed, Nov 29, 2017 at 12:34 AM, D Jayachandran <
> d.jayachandran@ericsson.com> wrote:
>
> > Hi Tal,
> >
> > I agree with your points mentioned below but I was thinking do we need
> > to have a ServiceLevel operation context, as we now have Node
> > operation context.
> >
> > Regards,
> > DJ
> > -----Original Message-----
> > From: Tal Liron [mailto:tal@cloudify.co]
> > Sent: Friday, November 24, 2017 10:12 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Support for extension point during service execution
> >
> > Hi DJ,
> >
> > The question here is why use ARIA's orchestrator at all? It sounds
> > like you have your own orchestration engine. This is an intended use
> > case for ARIA (and indeed was used in the OPEN-O project).
> >
> > There are a few ways to use ARIA here:
> >
> > 1) You can use the ARIA's Python API and access all the data models
> > directly. Of course this will only work if your own orchestration code
> > is in Python.
> > 2) You can use ARIA's CLI to emit the data models you need in either
> > JSON or YAML format, for easy consumption by your code: aria services
> > show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP
> service.
> > 3) You can access the database directly. ARIA uses a a normalized
> > relational (SQL) database.
> >
> > There are some challenges and limitations to each approach. If you
> > tell us what you're going to do we can help you move along in that
> direction.
> >
> >
> > On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <
> > d.jayachandran@ericsson.com
> > > wrote:
> >
> > > Hi Team,
> > >
> > > We are looking at an execution point during a service execution
> > > through a plugin. With this the execution will not go through the
> > > workflow runner
> > > (install/uninstall) defined by the orchestrator but the services
> > > instance context object will be provided to the plugin which will
> > > take care of the complete service-execution.
> > > This plugin is looked upon as a "service plugin" which will get the
> > > entire service model object and will provide the details to the
> > > external workflow engine.
> > > We need this feature to enable the execution of workflows which some
> > > of our users already have. Please let us know your thoughts on this
> > > as we have already started our technical study on this.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

RE: Support for extension point during service execution

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

Hi Tal,

For our use case we have already built a REST Layer on top of ARIA for service-template, services and execution creation/start.
Now for this particular use-case we were looking if we could take the service model object and create a service context object out of it, to be provided to the service level plugin.
I was thinking if we had to do this, can this be included as part of ARIA (Atleast creation of service context object)

Regards,
DJ
-----Original Message-----
From: Tal Liron [mailto:tal@cloudify.co] 
Sent: Wednesday, November 29, 2017 1:46 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for extension point during service execution

We half do. :) Actually, this has become a major topic of discussion recently on other lists. There's some room to discuss exactly what and how is available to the ctx proxy. Right now it's both too unrestricted and too narrow. The current idea is to make the exposure more explicit, and possibly align it with a more general REST API.

On Wed, Nov 29, 2017 at 12:34 AM, D Jayachandran < d.jayachandran@ericsson.com> wrote:

> Hi Tal,
>
> I agree with your points mentioned below but I was thinking do we need 
> to have a ServiceLevel operation context, as we now have Node 
> operation context.
>
> Regards,
> DJ
> -----Original Message-----
> From: Tal Liron [mailto:tal@cloudify.co]
> Sent: Friday, November 24, 2017 10:12 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for extension point during service execution
>
> Hi DJ,
>
> The question here is why use ARIA's orchestrator at all? It sounds 
> like you have your own orchestration engine. This is an intended use 
> case for ARIA (and indeed was used in the OPEN-O project).
>
> There are a few ways to use ARIA here:
>
> 1) You can use the ARIA's Python API and access all the data models 
> directly. Of course this will only work if your own orchestration code 
> is in Python.
> 2) You can use ARIA's CLI to emit the data models you need in either 
> JSON or YAML format, for easy consumption by your code: aria services 
> show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP service.
> 3) You can access the database directly. ARIA uses a a normalized 
> relational (SQL) database.
>
> There are some challenges and limitations to each approach. If you 
> tell us what you're going to do we can help you move along in that direction.
>
>
> On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran < 
> d.jayachandran@ericsson.com
> > wrote:
>
> > Hi Team,
> >
> > We are looking at an execution point during a service execution 
> > through a plugin. With this the execution will not go through the 
> > workflow runner
> > (install/uninstall) defined by the orchestrator but the services 
> > instance context object will be provided to the plugin which will 
> > take care of the complete service-execution.
> > This plugin is looked upon as a "service plugin" which will get the 
> > entire service model object and will provide the details to the 
> > external workflow engine.
> > We need this feature to enable the execution of workflows which some 
> > of our users already have. Please let us know your thoughts on this 
> > as we have already started our technical study on this.
> >
> >
> > Regards,
> > DJ
> >
>

Re: Support for extension point during service execution

[Tal Liron <ta...@cloudify.co>]

We half do. :) Actually, this has become a major topic of discussion
recently on other lists. There's some room to discuss exactly what and how
is available to the ctx proxy. Right now it's both too unrestricted and too
narrow. The current idea is to make the exposure more explicit, and
possibly align it with a more general REST API.

On Wed, Nov 29, 2017 at 12:34 AM, D Jayachandran <
d.jayachandran@ericsson.com> wrote:

> Hi Tal,
>
> I agree with your points mentioned below but I was thinking do we need to
> have a ServiceLevel operation context, as we now have Node operation
> context.
>
> Regards,
> DJ
> -----Original Message-----
> From: Tal Liron [mailto:tal@cloudify.co]
> Sent: Friday, November 24, 2017 10:12 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for extension point during service execution
>
> Hi DJ,
>
> The question here is why use ARIA's orchestrator at all? It sounds like
> you have your own orchestration engine. This is an intended use case for
> ARIA (and indeed was used in the OPEN-O project).
>
> There are a few ways to use ARIA here:
>
> 1) You can use the ARIA's Python API and access all the data models
> directly. Of course this will only work if your own orchestration code is
> in Python.
> 2) You can use ARIA's CLI to emit the data models you need in either JSON
> or YAML format, for easy consumption by your code: aria services show
> myservice --json. Note that you can also wrap ARIA's CLI in an HTTP service.
> 3) You can access the database directly. ARIA uses a a normalized
> relational (SQL) database.
>
> There are some challenges and limitations to each approach. If you tell us
> what you're going to do we can help you move along in that direction.
>
>
> On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <
> d.jayachandran@ericsson.com
> > wrote:
>
> > Hi Team,
> >
> > We are looking at an execution point during a service execution
> > through a plugin. With this the execution will not go through the
> > workflow runner
> > (install/uninstall) defined by the orchestrator but the services
> > instance context object will be provided to the plugin which will take
> > care of the complete service-execution.
> > This plugin is looked upon as a "service plugin" which will get the
> > entire service model object and will provide the details to the
> > external workflow engine.
> > We need this feature to enable the execution of workflows which some
> > of our users already have. Please let us know your thoughts on this as
> > we have already started our technical study on this.
> >
> >
> > Regards,
> > DJ
> >
>

RE: Support for extension point during service execution

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

Hi Tal,

I agree with your points mentioned below but I was thinking do we need to have a ServiceLevel operation context, as we now have Node operation context.

Regards,
DJ
-----Original Message-----
From: Tal Liron [mailto:tal@cloudify.co] 
Sent: Friday, November 24, 2017 10:12 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for extension point during service execution

Hi DJ,

The question here is why use ARIA's orchestrator at all? It sounds like you have your own orchestration engine. This is an intended use case for ARIA (and indeed was used in the OPEN-O project).

There are a few ways to use ARIA here:

1) You can use the ARIA's Python API and access all the data models directly. Of course this will only work if your own orchestration code is in Python.
2) You can use ARIA's CLI to emit the data models you need in either JSON or YAML format, for easy consumption by your code: aria services show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP service.
3) You can access the database directly. ARIA uses a a normalized relational (SQL) database.

There are some challenges and limitations to each approach. If you tell us what you're going to do we can help you move along in that direction.


On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <d.jayachandran@ericsson.com
> wrote:

> Hi Team,
>
> We are looking at an execution point during a service execution 
> through a plugin. With this the execution will not go through the 
> workflow runner
> (install/uninstall) defined by the orchestrator but the services 
> instance context object will be provided to the plugin which will take 
> care of the complete service-execution.
> This plugin is looked upon as a "service plugin" which will get the 
> entire service model object and will provide the details to the 
> external workflow engine.
> We need this feature to enable the execution of workflows which some 
> of our users already have. Please let us know your thoughts on this as 
> we have already started our technical study on this.
>
>
> Regards,
> DJ
>

Re: Support for extension point during service execution

[Tal Liron <ta...@cloudify.co>]

Hi DJ,

The question here is why use ARIA's orchestrator at all? It sounds like you
have your own orchestration engine. This is an intended use case for ARIA
(and indeed was used in the OPEN-O project).

There are a few ways to use ARIA here:

1) You can use the ARIA's Python API and access all the data models
directly. Of course this will only work if your own orchestration code is
in Python.
2) You can use ARIA's CLI to emit the data models you need in either JSON
or YAML format, for easy consumption by your code: aria services show
myservice --json. Note that you can also wrap ARIA's CLI in an HTTP service.
3) You can access the database directly. ARIA uses a a normalized
relational (SQL) database.

There are some challenges and limitations to each approach. If you tell us
what you're going to do we can help you move along in that direction.


On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <d.jayachandran@ericsson.com
> wrote:

> Hi Team,
>
> We are looking at an execution point during a service execution through a
> plugin. With this the execution will not go through the workflow runner
> (install/uninstall) defined by the orchestrator but the services instance
> context object will be provided to the plugin which will take care of the
> complete service-execution.
> This plugin is looked upon as a "service plugin" which will get the entire
> service model object and will provide the details to the external workflow
> engine.
> We need this feature to enable the execution of workflows which some of
> our users already have. Please let us know your thoughts on this as we have
> already started our technical study on this.
>
>
> Regards,
> DJ
>