Why are triggers and rules under package in manifest.yml?

[jzaccone]

From the OpenWhisk getting started documentation:

Triggers cannot be created inside a package; they must be created directly under a namespace.

So why are triggers and rules underneath package in manifest.yml?

package:
  actions:
  ...
  triggers:
    ...
  rules:
    ...

[mrutkows]

Packages are compositional units, they can be composed into other packages (and form applications or services) and provide linkage to larger Orchestration templating, much as what you see in AWS Cloud Formation.

[mrutkows]

In addition, packages are units of delivery (catalog) and can be versioned, ascribed metadata, etc. as a whole.

[rabbah]

I think john's point is that you can't create a trigger or rule inside a package so that's at odds with the principles you just outlined.

[mrutkows]

@rabbah I see. Semantically, we have a conflict then since we established Package to mean a collection of Actions; whereas, we were trying to use it for a broader "packaging" of related whisk entities for publishing. We have discussed using the term "service" or "bundle" (or "application" which was deemed too broad). Good time to discuss again. How would a user be able to provide these related things (rules, feeds, triggers) and know they are associated?

[jzaccone]

@mrutkows Good question.

I feel like this abstraction should extend to the OpenWhisk project itself. Shouldn't the goal of the wskdeploy tool to mirror the abstractions defined on the OpenWhisk platform?

In a way, these things (rules, feeds, triggers) are all associated if they are defined in the same manifest.yml file. Since they aren't reusable in the OpenWhisk platform itself, whats the advantages of having another layer that OW doesn't understand?

(I haven't been working on OW that long, just throwing out ideas based on what I have learned so far)

[paulcastro]

wskdeploy assumes everything is associated to a package, even though this is not true for triggers and rules. I did some internal refactoring (I changed the data structure so that triggers and rules are no longer contained in a package struct) because of this issue. However, this isn't surfaced in the Manifest. My current thought is that containment in a package is a useful abstraction to provide a default scope when writing out a manifest file. Basically, we can reduce typing. For example, right now you can write:

package:
  name: MyPackage
  actions:
    greeting:
      inputs:
        name: name
          type: string
 triggers:
      myTrigger
 rules:
    myRule:
      trigger: myTrigger
      action: greeting

In the actual deployment, we deploy MyPackage/greeting, myTrigger, myRule. However, we don't make the developer write out MyPackage/greeting in the rule definition. We just assume that any entity that doesn't explicitly state a package is contained in MyPackage.

I believe this still works when we add the dependency key (issue #41). In this case, we could have a dependent package named YourPackage. We could use the greeting action declared in YourPackage:

package:
  name: MyPackage
  dependencies:
     YourPackage:
           git: https://somegit
  actions:
    greeting:
      inputs:
        name: name
          type: string
 triggers:
      myTrigger
 rules:
    myRule:
      trigger: myTrigger
      action: greeting
   yourRule:
      trigger: myTrigger
      action: YourPackage/greeting

I don't know how you might reference a trigger in a dependent package in a unique way right now since internally we don't support triggers in packages. We could just modify the trigger name somehow?

[lionelvillard]

I tend to agree with @jzaccone, wskdeploy should follow the openwhisk terminology, and as such not have triggers under package. This is particularly confusing especially for newcomers.

In my opinion, bundle and module are both valid option.

This extra layer opens the door for having multiple packages under a single "project". This might be desirable or not.

[mrutkows]

We need to challenge the whisk terminology; package is not a strong concept other than to those that have learned the CLI. @lionelvillard. @paulcastro I wish we could have discussed this before making the change. A "package" construct should exist to describe everything packaged in a filesystem/directory or eventually a zip provided for related entities; which I still contend is universally known as a package (best term). Other than existing CLI bias for what a package is, what reason is there for not taking everything (all entities) that a developer created and calling them a package so that we can align with terms/catalogs such as Pypi, NPM, etc.? Instead why do we not simple call what is now a OW Package, a "Collection of Actions" which is what it is reduced to?

[mrutkows]

@paulcastro if you indeed changed the code then the spec. is no longer correct and we lack a substitute construct.

[paulcastro]

The change I made is only in an internal data structure to remove the need to pass package name as a parameter when indexing a trigger or rule. It was meaningless since triggers and rules don't require this in OW.

The manifest parsing itself is unchanged so the spec is still valid. Maybe the indents aren't so clear in my previous comment?

@lionelvillard one problem with moving triggers and rules out of the package is that it will be hard to share trigger and rule definitions between packages. I think it would be better if OW allowed triggers and rules to be in packages. However, I do agree that having the wskdeploy tool add an abstraction that isn't really there is confusing to new users. Could this just be documented somewhere?

[lionelvillard]

@mrutkows

package is not a strong concept other than to those that have learned the CLI.

Is this true? I was under the impression that the concept of package is core to OpenWhisk:

• https://github.com/openwhisk/openwhisk/blob/master/docs/reference.md#openwhisk-entities
• https://github.com/openwhisk/openwhisk/blob/master/docs/reference.md#rest-api

Disclaimer: I'm new to the OpenWhisk world, so bear with me.

[mrutkows]

@lionelvillard Someone made the decision to namespace in this way; we have already seen issues with it going forward. Conceptually, what constitutes a package can and should be questioned in light of becoming accepted and part of a larger service/packaging ecosystem.

These documents describe the state as it is today, based upon someone's decision to call a collection of Actions a package (and a component of OW's concept of a namespace which is yet to be described in terms of global service namespaces). IMO, it should be more expansive to allow namespacing of other OW entities.

[lionelvillard]

There is a proposal to have triggers/rules inside a package for v2: https://github.com/openwhisk/openwhisk/issues/219#issuecomment-272951007

(thanks Rodric)

[mrutkows]

@rabbah @lionelvillard Excellent! As we add more compositions this will become important.

[mrutkows]

@pritidesai FYI