Hi Steve, Let's just call it ARIA (the "ng" next-gen suffix was a temporary development code, no longer necessary as everything is merged into the Apache repository).
The Python workflow function doesn't actually execute the operations. Its job is to create the workflow graph based on the topology. The graph is a series of interdependent tasks that usually just execute a TOSCA operation on an interface of a node, a relationship, or a group. For example, the normative TOSCA "install" workflow has a series of interdependent operations to install, configure, and start nodes and operations, based on the TOSCA normative lifecycle interfaces. (See the TOSCA spec for more details.) Your own custom workflows will likely use your own custom interfaces and operation with their own define dependencies. That's where you need Python to build that graph. Actually, most workflow functions are quite short: there's not a lot of Python to write here. Once the workflow Python function creates the graph, an "executor" actually handles the execution of the tasks. ARIA's built-in executor can run the tasks either locally (on the machine running ARIA) or remotely via SSH, and expects these "implementations" to be be simple executable artifacts, such as shell scripts, that can be included in the CSAR. That's all standard TOSCA behavior. The executor API, though, is extensible and we expect many useful executors in the future. We have some support for Celery, and will also expect Puppet, Chef, and Juju. So a task, for example, could execute a Juju charm rather than just run a shell script. All of these products have their own rich debugging tools. That said, We've also put a lot of effort into the logging mechanism: logs are stores in the database (SQL), and are marked per workflow execution and per service, so even if you are running a large number of workflows you can still pinpoint the error without rummaging through mountains of text logs. The CLI lets you access these logs, though you can read the database via your own monitoring and analytics tools. So, if an individual task fails, the error message will be logged at this high level. It's also worth pointing out that even the task API is extensible. Though usually you want to execute TOSCA operations as part of your workflow, you can include your own custom tasks as part of the workflow, for domain-specific operations that are just not relevant to the TOSCA topology. (For example, a task to discover a controller, register a transaction, etc.) The CLI is quite rich in other aspects, including tools to display the topology in depth and understand what might have gone wrong. Obviously, this is an ongoing effort and we would very much appreciate feedback on how to improve debugging and workflow construction. Of course we look forward to TOSCA 1.1 finalizing and allowing a way to define these workflow graphs in YAML, although from experience we expect that YAML might not be good enough for some especially complex workflows. But, we'll wait and see, TOSCA 1.1 is also an ongoing effort. We're also missing a guide and examples for how to do all this. For now, we are here to help on the mailing list! On Tue, Jul 4, 2017 at 5:54 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Hi > Good information. > How does the user troubleshoot a Python script that is not properly > executed by ARIA NG? > Any support for CLI or API to inform client and provide cause/reason for > error? > > -Steve B > > -----Original Message----- > From: Ran Ziv [mailto:r...@gigaspaces.com] > Sent: Tuesday, July 04, 2017 4:23 AM > To: dev@ariatosca.incubator.apache.org > Subject: Re: imperative workflows (1.1) > > Yup. We have given some thought as to how to implement 1.1 workflows > including conditional tasks ("on_success"/"on_failure") and it maps well > into the workflow engine, but generally speaking supporting TOSCA 1.1 is > not currently a top item. > > On Tue, Jul 4, 2017 at 8:12 AM, Tal Liron <t...@gigaspaces.com> wrote: > > > Not exactly. We do not support TOSCA 1.1 imperative workflows and it's > > not on the roadmap. Our current plan is to provide a state-of-the-art > > TOSCA 1.0 implementation, and we're not at 100% completion yet. > > > > That said, we support something we call "custom workflows". They are > > not defined directly in TOSCA, but rather in a Python function > > indicated by a TOSCA policy (of type aria.Workflow). > > > > To be honest, you can do a lot more with Python than with TOSCA, but > > of course we understand that Python is not an option for many users. > > And of course this is an optional feature. > > > > Bottom line: we do not support TOSCA 1.1 right now, but have a very > > powerful workaround. > > > > On Mon, Jul 3, 2017 at 3:01 PM, DeWayne Filppi > > <dewa...@gigaspaces.com> > > wrote: > > > > > Is there any current support for imperative workflows (ala 1.1)? If > > > not, is it a priority roadmap item? > > > > > > --DeWayne > > > > > > > > > > > -- > > Tal Liron, Senior Solutions Architect <http://cloudify.co> > > ------------------------------ > > M: +1-312-375-8299 http://cloudify.co @cloudifysource > > <https://twitter.com/CloudifySource> > > <https://www.linkedin.com/company-beta/17918192/> > > <https://github.com/cloudify-cosmo> > > <https://www.youtube.com/cloudifysource> > > > -- Tal Liron, Senior Solutions Architect <http://cloudify.co> ------------------------------ M: +1-312-375-8299 http://cloudify.co @cloudifysource <https://twitter.com/CloudifySource> <https://www.linkedin.com/company-beta/17918192/> <https://github.com/cloudify-cosmo> <https://www.youtube.com/cloudifysource>