Reviewed entities (#47)

* chore: disabled repo

Disabled links on right sidebar

* docs: entities

Reviewed entities

content/en/docs/reference/entities/_index.md

@@ -1,19 +1,7 @@
 ---
 title: Entities
+description: 
+weight: 10
 ---
-You can find more informations about OpenServerless and OpenWhisk entities
-here:
 
-- [Actions](#actions.adoc)
-
-- [Parameters](#parameters.adoc)
-
-- [Annotations](#annotations.adoc)
-
-- [Scheduler](#scheduler.adoc)
-
-- [Web Actions](#webactions.adoc)
-
-- [Packages](#packages.adoc)
-
-- [Feeds](#feeds.adoc)
+In this section you can find more informations about OpenServerless and OpenWhisk entities.

content/en/docs/reference/entities/actions/_index.md

@@ -12,23 +12,21 @@ call, or post a Tweet. In general, an action is invoked in response to
 an event and produces some observable output.
 
 An action may be created from a function programmed using a number of
-[supported languages and
-runtimes](/docs/reference/index-runtimes), or from a
+[supported languages and runtimes](/docs/reference/runtimes/), or from a
 binary-compatible executable.
 
 - The OpenServerless CLI makes it easy to create and invoke actions.
     Instructions for configuring and using the CLI are available
     [here](/docs/cli/).
 
-- You can also use the [REST
-    API](/docs/reference/rest_api/).
+- You can also use the [REST API](/docs/reference/rest_api/).
 
 While the actual function code will be specific to a [language and
-runtime](/docs/reference/index-runtimes/), the operations to
+runtime](/docs/reference/runtimes/), the operations to
 create, invoke and manage an action are the same regardless of the
 implementation choice.
 
-We recommend that you review [the cli](#../../cli/index.adoc) and read
+We recommend that you review [the cli](/docs/cli/) and read
 [the tutorial](#../../tutorial/index.adoc) before moving on to advanced
 topics.
 
@@ -88,7 +86,7 @@ OpenWhisk and OpenServerless Docker skeleton.
 - `__OW_API_KEY` the API key for the subject invoking the action, this
     key may be a restricted API key. This property is absent unless
     requested with the annotation explicitly
-    [`provide-api-key`](#../../reference/annotations/index.adoc#annotations-for-all-actions)
+    [`provide-api-key`](/docs/reference/entities/annotations/#annotations-for-all-actions)
 
 - `__OW_NAMESPACE` the namespace for the *activation* (this may not be
     the same as the namespace for the action).

content/en/docs/reference/entities/annotations/_index.md

@@ -1,8 +1,10 @@
 ---
 title: Annotations
-weigth: 40
+description: How to use annotations to decorate actions
+weight: 40
 ---
-# Annotations
+
+## Annotations
 
 OpenWhisk and OpenServerless actions, triggers, rules and packages
 (collectively referred to as assets) may be decorated with
@@ -78,6 +80,8 @@ The annotations are *not* checked. So while it is conceivable to use the
 annotations to infer if a composition of two actions into a sequence is
 legal, for example, the system does not yet do that.
 
+## Annotations for all actions
+
 The following annotations on an action are available.
 
 - `provide-api-key`: This annotation may be attached to actions which
@@ -87,20 +91,19 @@ The following annotations on an action are available.
     absence of this annotation, or its presence with a value that is not
     *falsy* (i.e., a value that is different from zero, null, false, and
     the empty string) will cause an API key to be present in the [action
-    execution
-    context](#actions.adoc#accessing-action-metadata-within-the-action-body).
+    execution context](../actions/#accessing-action-metadata-within-the-action-body).
 
-# Annotations specific to web actions
+## Annotations specific to web actions
 
 Web actions are enabled with explicit annotations which decorate
 individual actions. The annotations only apply to the [web
-actions](#webactions.adoc) API, and must be present and explicitly set
+actions](../webactions/) API, and must be present and explicitly set
 to `true` to have an affect. The annotations have no meaning otherwise
 in the system. The annotations are:
 
 - `web-export`: Makes its corresponding action accessible to REST
     calls *without* authentication. We call these [*web
-    actions*](#webactions.adoc) because they allow one to use OpenWhisk
+    actions*](../webactions/) because they allow one to use OpenWhisk
     and OpenServerless actions from a browser for example. It is important to
     note that the *owner* of the web action incurs the cost of running
     them in the system (i.e., the *owner* of the action also owns the
@@ -118,7 +121,7 @@ in the system. The annotations are:
 
 - `web-custom-options`: When set, this annotation enables a web action
     to respond to OPTIONS requests with customized headers, otherwise a
-    [default CORS response](#webactions.adoc#options-requests) applies.
+    [default CORS response](../webactions/#options-requests) applies.
 
 - `require-whisk-auth`: This annotation protects the web action so
     that it is only invoked by requests that provide appropriate
@@ -133,7 +136,7 @@ in the system. The annotations are:
     system (i.e., the *owner* of the action also owns the activations
     record).
 
-# Annotations specific to activations
+## Annotations specific to activations
 
 The system decorates activation records with annotations as well. They
 are:

content/en/docs/reference/entities/feeds/_index.md

@@ -1,8 +1,8 @@
 ---
 title: Feeds
+description: Implement Feeds
 weight: 60
 ---
-# Implementing feeds
 
 OpenWhisk and OpenServerless support an open API, where any user can expose
 an event producer service as a **feed** in a **package**. This section
@@ -13,34 +13,34 @@ This material is intended for advanced OpenWhisk and OpenServerless users who
 intend to publish their own feeds. Most OpenWhisk and OpenServerless users
 can safely skip this section.
 
-# Feed Architecture
+## Feed Architecture
 
 There are at least 3 architectural patterns for creating a feed:
 **Hooks**, **Polling** and **Connections**.
 
-## Hooks
+### Hooks
 
 In the *Hooks* pattern, we set up a feed using a
 [webhook](https://en.wikipedia.org/wiki/Webhook) facility exposed by
 another service. In this strategy, we configure a webhook on an external
 service to POST directly to a URL to fire a trigger. This is by far the
 easiest and most attractive option for implementing low-frequency feeds.
 
-## Polling
+### Polling
 
 In the `Polling` pattern, we arrange for an OpenWhisk and OpenServerless
 *action* to poll an endpoint periodically to fetch new data. This
 pattern is relatively easy to build, but the frequency of events will of
 course be limited by the polling interval.
 
-## Connections
+### Connections
 
 In the `Connections` pattern, we stand up a separate service somewhere
 that maintains a persistent connection to a feed source. The connection
 based implementation might interact with a service endpoint via long
 polling, or to set up a push notification.
 
-# Difference between Feed and Trigger
+## Difference between Feed and Trigger
 
 Feeds and triggers are closely related, but technically distinct
 concepts.
@@ -61,13 +61,14 @@ concepts.
     services which produce the events, via a REST API that manages
     notifications.
 
-# Implementing Feed Actions
+## Implementing Feed Actions
 
 The *feed action* is a normal OpenWhisk and OpenServerless *action*, but it
-should accept the following parameters: \* **lifecycleEvent**: one of
-‘CREATE’, ‘READ’, ‘UPDATE’, ‘DELETE’, ‘PAUSE’, or ‘UNPAUSE’. \*
-**triggerName**: the fully-qualified name of the trigger which contains
-events produced from this feed. \* **authKey**: the Basic auth
+should accept the following parameters: 
+ - **lifecycleEvent**: one of ‘CREATE’, ‘READ’, ‘UPDATE’, ‘DELETE’, ‘PAUSE’, or ‘UNPAUSE’. 
+ - **triggerName**: the fully-qualified name of the trigger which contains
+events produced from this feed.
+- **authKey**: the Basic auth
 credentials of the OpenWhisk and OpenServerless user who owns the trigger
 just mentioned.
 
@@ -101,7 +102,7 @@ architecture. We’ll discuss the other architectures below.
 A similar feed action protocol occurs for `ops trigger delete`,
 `ops trigger update` and `ops trigger get`.
 
-# Implementing Feeds with Hooks
+## Implementing Feeds with Hooks
 
 It is easy to set up a feed via a hook if the event producer supports a
 webhook/callback facility.
@@ -124,7 +125,7 @@ defining parameters on the trigger event. OpenWhisk and OpenServerless rules
 pass these trigger parameters to any actions to fire as a result of the
 event.
 
-# Implementing Feeds with Polling
+## Implementing Feeds with Polling
 
 It is possible to set up an OpenWhisk and OpenServerless *action* to poll a
 feed source entirely within OpenWhisk and OpenServerless, without the need to
@@ -148,7 +149,7 @@ This procedure implements a polling-based trigger entirely using
 OpenWhisk and OpenServerless actions, without any need for a separate
 service.
 
-# Implementing Feeds via Connections
+## Implementing Feeds via Connections
 
 The previous 2 architectural choices are simple and easy to implement.
 However, if you want a high-performance feed, there is no substitute for

content/en/docs/reference/entities/packages/_index.md

@@ -1,8 +1,8 @@
 ---
 title: Packages
+description: Create and Use packages
 weight: 50
 ---
-# Using and creating packages
 
 In OpenWhisk and OpenServerless, you can use packages to bundle together a
 set of related actions, and share them with others.
@@ -17,7 +17,7 @@ fire a trigger at a specified frequency.
 Every OpenWhisk and OpenServerless entity, including packages, belongs in a
 *namespace*, and the fully qualified name of an entity is
 `/namespaceName[/packageName]/entityName`. Refer to the [naming
-guidelines](#reference.adoc#openwhisk-entities) for more information.
+guidelines](/docs/reference/references/naming-limits/#entities) for more information.
 
 The following sections describe how to browse packages and use the
 triggers and feeds in them. In addition, if you are interested in
@@ -55,7 +55,7 @@ and get a description of the individual entities in a package.
 
 **Note**: Parameters listed under the package with a prefix `*` are
 predefined, bound parameters. Parameters without a `*` are those listed
-under the [annotations](#annotations.adoc) for each entity. Furthermore,
+under the [annotations](/docs/reference/entities/annotations/) for each entity. Furthermore,
 any parameters with the prefix `**` are finalized bound parameters. This
 means that they are immutable, and cannot be changed by the user. Any
 entity listed under a package inherits specific bound parameters from

content/en/docs/reference/entities/parameters/_index.md

@@ -1,7 +1,11 @@
 ---
 title: Parameters
+description: Supply data to actions adding parameters
 weight: 30
 ---
+
+## Introduction to parameters
+
 When working with serverless actions, data is supplied by adding
 parameters to the actions; these are in the parameter declared as an
 argument to the main serverless function. All data arrives this way and
@@ -19,11 +23,10 @@ is also information on how to use a file to store the parameters and
 pass the filename, rather than supplying each parameter individually on
 the command-line.
 
-# Passing parameters to an action at invoke time
+## Passing parameters to an action at invoke time
 
 Parameters can be passed to the action when it is invoked. These
-examples use JavaScript but all [the other
-languages](#index-runtimes.adoc) work the same way.
+examples use JavaScript but all [the other languages](/docs/reference/runtimes/) work the same way.
 
 1. Use parameters in the action. For example, create ‘hello.js’ file
     with the following content:
@@ -80,7 +83,7 @@ The result is the same because the CLI automatically parses the `person`
 parameter value into the structured object that the action now expects:
 `json { "payload": "Hello, Dorothy from Kansas" }`
 
-# Setting default parameters on an action
+## Setting default parameters on an action
 
 Actions can be invoked with multiple named parameters. Recall that the
 `hello` action from the previous example expects two parameters: the
@@ -93,7 +96,7 @@ parameter so that the action defaults to the place “Kansas”:
 1. Update the action by using the `--param` option to bind parameter
     values, or by passing a file that contains the parameters to
     `--param-file` (for examples of using files, see the section on
-    [working with parameter files](##working-with-parameter-files)).
+    [working with parameter files](#working-with-parameter-files).
 
 To specify default parameters explicitly on the command-line, provide a
 key/value pair to the `param` flag:
@@ -128,7 +131,7 @@ specifying the parameter value at invocation time.
 Despite a parameter set on the action when it was created/updated, this
 is overridden by a parameter that was supplied when invoking the action.
 
-# Setting default parameters on a package
+## Setting default parameters on a package
 
 Parameters can be set at the package level, and these will serve as
 default parameters for actions unless:
@@ -167,7 +170,7 @@ package and shows an action making use of it.
            "payload": "Hello, World"
        }
 
-\# Working with parameter files
+## Working with parameter files
 
 It’s also possible to put parameters into a file in JSON format, and
 then pass the parameters in by supplying the filename with the