[Slack] Notifications from the ASF team for July 5th, 2017 at 8:17 AM

[Slack]

Hi ARIA TOSCA,

You have a new direct message from the ASF team
(https://the-asf.slack.com/x-185534614710-207946102244/).

---

@digestai
View in the archives:
https://the-asf.slack.com/x-185534614710-207946102244/archives/D5E4SCANM/p1499230890323142

Digest.AI (8:01 AM, July 5th)
Hi ARIA,
*Here’s your digest for July 5th 2017*
There are 28 messages yesterday, and the most active user is smarthi

*#ariatosca*
 @smarthi: is there anyway all of those Jira and commit notifications be
redirected to a different mail box
 maybe commits@ariatosca..
 no offense to anyone but being notified of any commit/push amounts to
spam….
 if something like commits@ariatosca.. is not already setup
 we can ask infra to do it
 QED
 @avia: Hi smarthi, these messages are sent only to the issues mailing
list, and to the commits mailing list (that already exists). Do you want
them redirected only to the commits mailing list? In my opinion, the
Jira mails seems relevant to the issues list also.
 @avia: Upon further inspection, the Jira mails are sent only to the
issues list, and the commit mails are sent only to the commits list.





* * *

You can snooze these notifications for
an hour:
https://the-asf.slack.com/unsub/U5FFQJ2LW-5a1cb74d28-notify-mute-1h
eight hours:
https://the-asf.slack.com/unsub/U5FFQJ2LW-796e6535e1-notify-mute-8h
a day:
https://the-asf.slack.com/unsub/U5FFQJ2LW-4e6e073ada-notify-mute-1d
three days:
https://the-asf.slack.com/unsub/U5FFQJ2LW-806a2d8aa0-notify-mute-3d
or the next week:
https://the-asf.slack.com/unsub/U5FFQJ2LW-6adc840c34-notify-mute-7d.

You can also turn email notifications off:
https://the-asf.slack.com/unsub/U5FFQJ2LW-64de78982b-notify.

For more detailed preferences, see your account page:
https://the-asf.slack.com/account.

Re: imperative workflows (1.1)

[Tal Liron]

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  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
> > 
> > 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 

RE: imperative workflows (1.1)

[Steve Baillargeon]

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  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 
> 
> 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 
> --
> M: +1-312-375-8299 http://cloudify.co @cloudifysource 
> 
> 
> 
> 
>

Re: [VOTE] publish ariatosca 0.1.0 (#2)

[Avia Efrat]

1) Validated signature & checksums
2) Validated LICENSE, NOTICE, DISCLAIMER, "incubating" in archive name
3) Made a clean install using "pip install ."
4) Ran tests using "make test"

+1

On Mon, Jul 3, 2017 at 3:39 PM, Suneel Marthi  wrote:

> +1 binding
>
> 1. Verified {sdist, bdist, source} * {sha, md5} hashes and sigs
> 2. Built project from {source} with "pip install"
> 3. Ran tests
> 4. Verified -incubating in artifacts names.
>
>
> On Mon, Jul 3, 2017 at 7:13 AM, John D. Ament 
> wrote:
>
> > On Sun, Jul 2, 2017 at 9:18 AM Ran Ziv  wrote:
> >
> > > Okay. I didn't have anything to go by since as far as I can tell, other
> > > projects don't put their PyPI package candidates on /dist/dev, but to
> my
> > > understanding, in the previous voting thread you've requested to have
> it
> > on
> > > there as well.
> > >
> >
> > Nope, the only package I care about is source.  Having the others is an
> ace
> > in the hole though, since it's covering the source, binary and sdist
> > releases needed by pypi (FWIW, there was an effort to spin up an internal
> > pypi service but it's stalled).  When we verify, we can verify the full
> > package.  Now I know more about pypi dist's to be able to push back when
> > other projects publish bad releases.
> >
> > Here's my +1 to release as is.
> >
> > I would recommend adding the instructions to the readme at some point,
> this
> > block:
> >
> > Instructions for installation etc. may be found in the README file inside
> > the tarball.
> > (Please note that the relevant installation instructions are for "source
> > installation", not "install from PyPI")
> >
> >
> > To use RAT to validate package conformance with ASF standards, please use
> > the ".rat-excludes" file, for example:
> > java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
> >
> >
> > In any case, I modified the layout as you'd requested.
> > >
> > > Regarding md5 and sha files, note that on PyPI only pgp signatures may
> be
> > > used. I added them regardless.
> > >
> > >
> > > Thanks,
> > > Ran
> > >
> > >
> > > On Sun, Jul 2, 2017 at 4:01 PM, John D. Ament 
> > > wrote:
> > >
> > > > Ran,
> > > >
> > > > I would recommend a different directory layout, to make it clear that
> > > these
> > > > are three different artifacts for the same release.  Most projects
> > > create a
> > > > version number below their project name, or just dump all of the
> files
> > in
> > > > the root (makes it easier to remember to clean up afterwards).
> > > >
> > > > Starting from
> > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > > 0.1.0-incubating/
> > > > create
> > > > "source", "sdist" and "bdist" directories.
> > > >
> > > > Put the current contents of this URL in "source" and move the other
> two
> > > to
> > > > the respective locations.  When sending out the vote, you only need
> to
> > > > include the root URL.  Or you can just dump everything directly into
> > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/ .
> > > >
> > > > For the contents in sdist and bdist, please include the md5 and sha
> > > files.
> > > >
> > > > John
> > > >
> > > > On Sun, Jul 2, 2017 at 8:40 AM Ran Ziv  wrote:
> > > >
> > > > > This is a vote to release Apache AriaTosca (Incubating) 0.1.0.
> > > > > If the vote passes, another vote for approving the release will
> take
> > > > place
> > > > > on the Apache Incubator's PMC.
> > > > >
> > > > >
> > > > > I created a tarball candidate for the 0.1.0 release and placed it
> in
> > > > ARIA's
> > > > > /dist/dev folder:
> > > > > *
> > > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > > 0.1.0-incubating/
> > > > > <
> > > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > > 0.1.0-incubating/
> > > > > >*
> > > > > The file is signed (.asc) and its MD5 / SHA512 checksums may be
> found
> > > in
> > > > > that folder as well.
> > > > >
> > > > >
> > > > > In addition, I've created packages for (Pythonic-)source & binary
> > > > > distributions, which would be uploaded to PyPI if the release is
> > > > approved.
> > > > > These artifacts may be found here:
> > > > > Source distribution:
> > > > >
> > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.1.0-sdist/
> > > > > Binary distribution:
> > > > >
> > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.1.0-bdist/
> > > > >
> > > > >
> > > > >
> > > > > The list of issues Resolved for this release are simply all the
> > issues
> > > > that
> > > > > have been resolved thus far, seeing as this would be the first
> > release
> > > :)
> > > > > Those can be found here:
> > > > > https://issues.apache.org/jira/browse/ARIA-295?filter=-1&;
> > > > > jql=project%3Dariatosca%20and%20status%20in%20(resolved%2C%
> 20closed)
> > > > >
> > > > >
> > > > > Instructions for installation etc. may be found in the README file
> > > inside
> > > > > the tarball.
> > > > > (Please note that the relevant installation instructions are for
> > >

AriaTosca website published

[Apache Jenkins Server]

The Apache Jenkins build system has built AriaTosca Website (build #12)

Status: Successful

Check console output at https://builds.apache.org/job/AriaTosca%20Website/12/ 
to view the results.

AriaTosca website published

[Apache Jenkins Server]

The Apache Jenkins build system has built AriaTosca Website (build #11)

Status: Successful

Check console output at https://builds.apache.org/job/AriaTosca%20Website/11/ 
to view the results.

Digest for ASF's Slack

[Digest]

Here’s your digest for today! 
#ariatosca
undefined: (p.s.: for the section about validating signatures, see 
 and 
 )
 (for the checksums, you can either use `sha512sum/md5sum`, or use `gpg 
--print-md MD5/SHA512 apache-ariatosca-0.1.0-incubating.tar.gz`)
undefined: <@U5416JV9R> when does the vote end for this release candidate
undefined: Wednesday July 5th 13:00 UTC :slightly_smiling_face:
undefined: ok the email calling for VOTE doesn’t say that
undefined: It says it'll last 72h, and emails have a receiving timestamp 
:sweat_smile:
undefined: yeah hard to pay attn on a long weekend
undefined: right, sorry, ill have the final time on the mail next time
undefined: [UPDATE] fixed and rebased my dangling PRs.

ARIA-287 - tox for docs. can't install latest Sphinx on py2.6, but that's OK 
because we really don't need to test doc creation on multiple environments

ARIA-260 - interface inputs. rebased and improved on the tests. btw, the test 
format i'm using there is close to what i hope a lot of our tests would look 
like: here's a template, here's the expected outputs, go.

ARIA-254 - multiple node support. this was a very painful rebase. :confused: 
git mangled a lot of stuff in models.

so, all three can be reviewed and merged as far as i'm concerned.

reminder that tomorrow is independence day in america, so i will sleeping ALL 
DAY.

Re: imperative workflows (1.1)

[Ran Ziv]

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  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 
> 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 
> --
> M: +1-312-375-8299 http://cloudify.co @cloudifysource
> 
> 
> 
> 
>