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 < [email protected]> 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:[email protected]] > Sent: Wednesday, November 29, 2017 1:46 PM > To: [email protected] > 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 < > [email protected]> 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:[email protected]] > > Sent: Friday, November 24, 2017 10:12 PM > > To: [email protected] > > 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 < > > [email protected] > > > 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 > > > > > >
