mrutkows commented on a change in pull request #862: Documentation for the 
export feature

 File path: docs/
 @@ -0,0 +1,300 @@
+# Using `wskdeploy` for exporting `OpenWhisk` assets
+`wskdeploy export` can be used to export `OpenWhisk` assets previously 
deployed as a *managed project* via `wskdeploy sync -m manifest.yaml`. 
`wskdeploy export` will create a manifest for the managed project assets and 
separate manifests for each managed project that this managed project depends 
upon, if such dependencies exist and have been described in `manifest.yml` when 
the managed project has been initially deployed.
+The manifest(s) resulting from executing `wskdeploy export` can be later used 
for deploying at a different `OpenWhisk` instance. The code of actions, which 
are defined in the packages of the exported project will be saved into folders 
with the names being the names of the package, the actions belong to.
+## Use Cases
+### Copy `OpenWhisk` Assets
+One common scenario, in which the export feature is useful, is populating a 
newly installed `OpenWhisk` instance with assets from 
+another `OpenWhisk` instance. One might consider a scenario, in which an 
`OpenWhisk` instance is installed on premises with another `OpenWhisk` instance 
residing in the cloud. Consider, for example using one `OpenWhisk` instance on 
premises and another one in the cloud (e.g., the second `OpenWhisk` instance 
can be [IBM Cloud Functions]( A fairly 
common scenario is that a developer
 Review comment:
   @davidbreitgand @pritidesai our docs should be devoid of any implementation 
reference where possible. Is there a way to generalize the use case?  e.g., 
provider A to provider B?

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

Reply via email to