Re: Loading Custom Workflows from CSAR
This is indeed the situation right now, but we're unhappy with it and it may be improved soon. On Fri, Dec 8, 2017 at 12:05 AM, Vaishnavi K.R <vaishnavi@ericsson.com> wrote: > Hi Tal, > > > The loading of the python modules with python functions for workflows > happens when the module is in PYTHONPATH. > > But I could also see that, the absolute path of the resource storage with > the service template ID is added to sys.path to make it available for > python. > > This facilitates the loading of modules from CSAR, provided the modules > are present in the root directory of the CSAR. > > Am I right? > > > Thanks, > > /Vaish > > > From: Tal Liron <t...@cloudify.co> > Sent: Thursday, December 7, 2017 8:51:49 PM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Loading Custom Workflows from CSAR > > Actually, the current implementation does not use the CSAR: it expects that > the Python function (decorated by @workflow) would be somewhere in the > Python path, and we are currently missing a CSAR code-loading mechanism. > > We do not expect the @workflow function structure to change in any way, so > I think you can feel confident about writing custom workflows in this > matter. What might change slightly in the near future is how to package the > .py file. > > > On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon < > steve.baillarg...@ericsson.com> wrote: > > > Hi > > While the investigation is on-going, I need to double check what can be > > done today. > > But I guess how it is done today might change as well (?) > > Based on our analysis of the latest code base, the loading of the custom > > workflows today is from CSAR only. > > Please advise. > > > > -Steve > > > > -----Original Message- > > From: Tal Liron [mailto:t...@cloudify.co] > > Sent: Tuesday, November 28, 2017 2:06 PM > > To: dev@ariatosca.incubator.apache.org > > Subject: Re: Loading Custom Workflows from CSAR > > > > Thanks, Steve. We don't have a JIRA for this right now, but we do intend > > to have a way to include "plugins" in a CSAR and have them automatically > > installed. A "plugin" is basically a Python extension to ARIA that can be > > loaded at runtime and contained per service. > > > > This is part of our current general work trying to find a good design for > > plugins generally, and will likely result in a JIRA epic with several > > issues. At this time, I don't think it's worth created this epic if we > > don't have a plan. > > > > The design will likely be inspired by the plugin design in Cloudify, from > > which we grabbed our seed code. However, there is room for some > > re-imagination especially as pertains TOSCA-specific issues. > > > > On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon < > > steve.baillarg...@ericsson.com> wrote: > > > > > Hi > > > As far as I know the implementation string associated with the > > > aria.Workflow type must call or execute a Python function (using the > > > dot > > > notation) that is stored in ARIA, like a plugin. > > > When will it be possible to refer to a .py file stored in the CSAR > > > instead? > > > Do you have any Jira for this enhancement? > > > > > > Regards > > > Steve B > > > > > >
Re: Loading Custom Workflows from CSAR
Hi Tal, The loading of the python modules with python functions for workflows happens when the module is in PYTHONPATH. But I could also see that, the absolute path of the resource storage with the service template ID is added to sys.path to make it available for python. This facilitates the loading of modules from CSAR, provided the modules are present in the root directory of the CSAR. Am I right? Thanks, /Vaish From: Tal Liron <t...@cloudify.co> Sent: Thursday, December 7, 2017 8:51:49 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Loading Custom Workflows from CSAR Actually, the current implementation does not use the CSAR: it expects that the Python function (decorated by @workflow) would be somewhere in the Python path, and we are currently missing a CSAR code-loading mechanism. We do not expect the @workflow function structure to change in any way, so I think you can feel confident about writing custom workflows in this matter. What might change slightly in the near future is how to package the .py file. On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Hi > While the investigation is on-going, I need to double check what can be > done today. > But I guess how it is done today might change as well (?) > Based on our analysis of the latest code base, the loading of the custom > workflows today is from CSAR only. > Please advise. > > -Steve > > -Original Message- > From: Tal Liron [mailto:t...@cloudify.co] > Sent: Tuesday, November 28, 2017 2:06 PM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Loading Custom Workflows from CSAR > > Thanks, Steve. We don't have a JIRA for this right now, but we do intend > to have a way to include "plugins" in a CSAR and have them automatically > installed. A "plugin" is basically a Python extension to ARIA that can be > loaded at runtime and contained per service. > > This is part of our current general work trying to find a good design for > plugins generally, and will likely result in a JIRA epic with several > issues. At this time, I don't think it's worth created this epic if we > don't have a plan. > > The design will likely be inspired by the plugin design in Cloudify, from > which we grabbed our seed code. However, there is room for some > re-imagination especially as pertains TOSCA-specific issues. > > On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon < > steve.baillarg...@ericsson.com> wrote: > > > Hi > > As far as I know the implementation string associated with the > > aria.Workflow type must call or execute a Python function (using the > > dot > > notation) that is stored in ARIA, like a plugin. > > When will it be possible to refer to a .py file stored in the CSAR > > instead? > > Do you have any Jira for this enhancement? > > > > Regards > > Steve B > > >
Re: Loading Custom Workflows from CSAR
Actually, the current implementation does not use the CSAR: it expects that the Python function (decorated by @workflow) would be somewhere in the Python path, and we are currently missing a CSAR code-loading mechanism. We do not expect the @workflow function structure to change in any way, so I think you can feel confident about writing custom workflows in this matter. What might change slightly in the near future is how to package the .py file. On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Hi > While the investigation is on-going, I need to double check what can be > done today. > But I guess how it is done today might change as well (?) > Based on our analysis of the latest code base, the loading of the custom > workflows today is from CSAR only. > Please advise. > > -Steve > > -Original Message- > From: Tal Liron [mailto:t...@cloudify.co] > Sent: Tuesday, November 28, 2017 2:06 PM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Loading Custom Workflows from CSAR > > Thanks, Steve. We don't have a JIRA for this right now, but we do intend > to have a way to include "plugins" in a CSAR and have them automatically > installed. A "plugin" is basically a Python extension to ARIA that can be > loaded at runtime and contained per service. > > This is part of our current general work trying to find a good design for > plugins generally, and will likely result in a JIRA epic with several > issues. At this time, I don't think it's worth created this epic if we > don't have a plan. > > The design will likely be inspired by the plugin design in Cloudify, from > which we grabbed our seed code. However, there is room for some > re-imagination especially as pertains TOSCA-specific issues. > > On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon < > steve.baillarg...@ericsson.com> wrote: > > > Hi > > As far as I know the implementation string associated with the > > aria.Workflow type must call or execute a Python function (using the > > dot > > notation) that is stored in ARIA, like a plugin. > > When will it be possible to refer to a .py file stored in the CSAR > > instead? > > Do you have any Jira for this enhancement? > > > > Regards > > Steve B > > >
Re: Loading Custom Workflows from CSAR
Thanks, Steve. We don't have a JIRA for this right now, but we do intend to have a way to include "plugins" in a CSAR and have them automatically installed. A "plugin" is basically a Python extension to ARIA that can be loaded at runtime and contained per service. This is part of our current general work trying to find a good design for plugins generally, and will likely result in a JIRA epic with several issues. At this time, I don't think it's worth created this epic if we don't have a plan. The design will likely be inspired by the plugin design in Cloudify, from which we grabbed our seed code. However, there is room for some re-imagination especially as pertains TOSCA-specific issues. On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Hi > As far as I know the implementation string associated with the > aria.Workflow type must call or execute a Python function (using the dot > notation) that is stored in ARIA, like a plugin. > When will it be possible to refer to a .py file stored in the CSAR > instead? > Do you have any Jira for this enhancement? > > Regards > Steve B >
