Merge pull request #315 from jeffngo/merge_3.0.0_master

Merge 'release/3.0.0' into master

Author: jeffngo

.bumpversion.cfg

@@ -1,5 +1,5 @@
 [bumpversion]
-current_version = 2.1.0
+current_version = 3.0.0
 commit = False
 tag = False
 parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\.(?P<release>[a-z]+)(?P<dev>\d+))?

.dependabot/config.yaml

@@ -3,21 +3,21 @@ update_configs:
   # Keep requirements.txt files up-to-date in each package.
   - package_manager: "python"
     directory: "/dvp"
-    update_schedule: "daily"
+    update_schedule: "monthly"
     target_branch: "develop"
   - package_manager: "python"
     directory: "/common"
-    update_schedule: "daily"
+    update_schedule: "monthly"
     target_branch: "develop"
   - package_manager: "python"
     directory: "/platform"
-    update_schedule: "daily"
+    update_schedule: "monthly"
     target_branch: "develop"
   - package_manager: "python"
     directory: "/libs"
-    update_schedule: "daily"
+    update_schedule: "monthly"
     target_branch: "develop"
   - package_manager: "python"
     directory: "/tools"
-    update_schedule: "daily"
+    update_schedule: "monthly"
     target_branch: "develop"

.github/CODEOWNERS

@@ -1 +1 @@
-*       @ankursarin @fdrozdowski @nhlien93 @crystalplumage
+*       @ankursarin @nhlien93 @mothslaw

.github/workflows/publish-docs.yml

@@ -33,8 +33,9 @@ jobs:
         run: |
           CURRENT_BRANCH_VAR=${GITHUB_REF#refs/heads/}
           echo "Current branch: $CURRENT_BRANCH_VAR"
-          # Set CURRENT_BRANCH environment variable to the current branch name.
-          echo "::set-env name=CURRENT_BRANCH::$(echo $CURRENT_BRANCH_VAR)"
+          # Set CURRENT_BRANCH environment variable to the current branch name. Refrain from using 'set-env' as
+          # GitHub has identified the command as a moderate security vulnerability.
+          echo "CURRENT_BRANCH=$(echo $CURRENT_BRANCH_VAR)" >> $GITHUB_ENV
       - name: Display all remote branches
         working-directory: ${{ matrix.package }}
         run: |
@@ -46,8 +47,9 @@ jobs:
           # Get only docs branches, extract the "docs/x.y.z" part, sort them in descending order, and get the first one.
           LATEST_DOCS_BRANCH_VAR=$(git branch -r | grep -e ".*\/*docs\/[0-9].[0-9].[0-9]" | sed -n "s/.*\/*\(docs\/[0-9].[0-9].[0-9]\).*/\1/p" | sort -r | head -n 1)
           echo "Latest docs branch: $LATEST_DOCS_BRANCH_VAR"
-          # Set the LATEST_DOCS_BRANCH environment variable.
-          echo "::set-env name=LATEST_DOCS_BRANCH::$(echo $LATEST_DOCS_BRANCH_VAR)"
+          # Set the LATEST_DOCS_BRANCH environment variable. Refrain from using 'set-env' as GitHub has identified the
+          # command as a moderate security vulnerability.
+          echo "LATEST_DOCS_BRANCH=$(echo $LATEST_DOCS_BRANCH_VAR)" >> $GITHUB_ENV
       - name: Check that the current branch is the latest docs branch, fail otherwise
         working-directory: ${{ matrix.package }}
         run: |

README-dev.md

@@ -125,17 +125,17 @@ To run blackbox tests, follow these steps:
 2. Navigate to the app-gate directory and start tests using `git blackbox`. For the guide on which test suite to use,
 see the next sections.
 
-At a minimum, each pull request should pass `appdata_python_samples` and `appdata_sanity` tests with a direct or staged plugin.
+At a minimum, each pull request should pass `appdata_python_samples` and `appdata_basic` tests with a direct or staged plugin.
 See the section below for the description of each test suite.
 
 #### Blackbox tests targeting wrappers (mostly Delphix Engine workflows)
 * appdata_python_samples (sample plugins from the app-gate):
 `git blackbox -s appdata_python_samples --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`,
-* appdata_sanity with a direct Python plugin on CentOS 7.3: `git blackbox -s appdata_sanity -c APPDATA_PYTHON_DIRECT_CENTOS73 -a --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`,
-* appdata_sanity with a staged Python plugin on CentOS 7.3: `git blackbox -s appdata_sanity -c APPDATA_PYTHON_STAGED_CENTOS73 -a --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`.
+* appdata_basic with a direct Python plugin on CentOS 7.3: `git blackbox -s appdata_basic -c APPDATA_PYTHON_DIRECT_CENTOS73 -a --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`,
+* appdata_basic with a staged Python plugin on CentOS 7.3: `git blackbox -s appdata_basic -c APPDATA_PYTHON_STAGED_CENTOS73 -a --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`.
 
 #### Blackbox tests targeting the CLI (~80% CLI tests)
 * virtualization_sdk (installs and tests a direct Python plugin on Ubuntu 18): 
 `git blackbox -s virtualization_sdk -c APPDATA_SDK_UBUNTU18_DIRECT_CENTOS73 --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`,
 * virtualization_sdk (installs and tests a staged Python plugin on Ubuntu 18): 
-`git blackbox -s virtualization_sdk -c APPDATA_SDK_UBUNTU18_STAGED_CENTOS73 --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`.
+`git blackbox -s virtualization_sdk -c APPDATA_SDK_UBUNTU18_STAGED_CENTOS73 --extra-params="-p virt-sdk-repo=https://github.com/<username>/virtualization-sdk.git -p virt-sdk-branch=my-feature"`.

common/setup.py

@@ -4,7 +4,7 @@
 PYTHON_SRC = 'src/main/python'
 
 install_requires = [
-  "dvp-api == 1.3.0",
+  "dvp-api == 1.4.0",
 ]
 
 with open(os.path.join(PYTHON_SRC, 'dlpx/virtualization/common/VERSION')) as version_file:

common/src/main/python/dlpx/virtualization/common/VERSION

@@ -1 +1 @@
-2.1.0
+3.0.0

docs/docs/Best_Practices/.pages

@@ -6,3 +6,4 @@ arrange:
   - Sensitive_Data.md
   - Unicode_Data.md
   - Working_with_Powershell.md
+  - Scratch_Paths.md

docs/docs/Best_Practices/Scratch_Paths.md

@@ -0,0 +1,19 @@
+#Scratch Paths
+
+A scratch path is a directory reserved for plugin use on each remote host. This is intended for uses such as:
+
+- Storage of small amounts of persistent data
+- A place to mount VDB data
+- Temporary logs for debugging (Be careful that you don't use too much space though!)
+
+The location of this scratch area is given by the `scratch_path` property on the [RemoteHost](/References/Classes/#remotehost) object.
+
+
+Things to note about the scratch path:
+
+- No guarantees are made about where the path is located on the system.
+- No guarantees are made about how much space might be available in this directory. It is strongly advised that you use only a small amount of disk space here.
+- The directory will be owned by the "primary user" associated with the remote host. This might be a completely different user from the one that is associated with a particular dsource or VDB.
+- If you need to store dSource- or VDB-specific data, it is highly recommended that you create a separate subdirectory for each dSource/VDB inside this scratch area. It's also recommended to name this subdirectory using the GUID of the dSource/VDB, so that you avoid accidental name collisions.
+- The Delphix Engine will not do any cleanup for you, so be sure to delete anything you're no longer using. For example, any VDB-specific information must be deleted in your [unconfigure](/References/Plugin_Operations/#virtual-source-unconfigure) operation (and dSource data gets deleted in your [stopStaging](/References/Plugin_Operations/#staged-linked-source-stop-staging) operation.)
+- Do not store any [sensitive information](Sensitive_Data.md) here!

docs/docs/Building_Your_First_Plugin/Data_Ingestion.md

@@ -21,7 +21,7 @@ quite limiting.
 
 For our first plugin, we will be using the more flexible [staging](/References/Glossary.md#staged-linkingsyncing) strategy. With this strategy, the Delphix Engine uses NFS for Unix environments (or iSCSI on Windows environments) to mount storage onto a [staging environment](/References/Glossary.md#staging-environment). Our plugin will then be in full control of how to get data from the source environment onto this storage mount.
 
-With the staging strategy, there are two types of syncs: sync and resync. A `sync` is used to ingestion incremental changes while a `resync` is used to re-ingest all the data for the dSource. For databases, this could mean re-ingesting from a full database backup to reset the dSource. A `sync` and a `resync` execute the same plugin operations and are differentiated by a boolean flag in the [snapshot_parameters](/References/Classes.md#snapshotparametersdefinition) argument passed into [linked.pre_snapshot](/References/Plugin_Operations.md#staged-linked-source-pre-snapshot) and [linked.post_snapshot](/References/Plugin_Operations.md#staged-linked-source-post-snapshot).
+With the staging strategy, there are two types of syncs: sync and resync. A `sync` is used to ingest incremental changes while a `resync` is used to re-ingest all the data for the dSource. For databases, this could mean re-ingesting from a full database backup to reset the dSource. A `sync` and a `resync` will execute the same plugin operations. To differentiate a `sync` from a `resync`, simply add a boolean property (i.e. `resync`) in the plugin's [snapshot parameters definition](References/Schemas_and_Autogenerated_Classes.md#snapshotparametersdefinition-schema). Once `sync` or `resync` is selected, the property will be passed into [linked.pre_snapshot](/References/Plugin_Operations.md#staged-linked-source-pre-snapshot) and [linked.post_snapshot](/References/Plugin_Operations.md#staged-linked-source-post-snapshot) as a [snapshot parameter](/References/Glossary.md#snapshot-parameters).
 
 A regular `sync` is the default and is executed as part of policy driven syncs. A `resync` is only executed during initial ingestion or if the Delphix user manually starts one. The customer can manually trigger a `resync` via the UI by selecting the dSource, going to more options and selecting **Resynchronize dSource**. ![Screenshot](images/Resync.png)
 
@@ -168,7 +168,7 @@ Next, we'll add a new function:
 
 ```python
 @plugin.linked.pre_snapshot()
-def copy_data_from_source(staged_source, repository, source_config, snapshot_parameters):
+def copy_data_from_source(staged_source, repository, source_config, optional_snapshot_parameters):
     stage_mount_path = staged_source.mount.mount_path
     data_location = "{}@{}:{}".format(staged_source.parameters.username,
         staged_source.parameters.source_address,
@@ -249,7 +249,7 @@ In fact, the default implementation that was generated by `dvp init` will work j
 def linked_post_snapshot(staged_source,
                          repository,
                          source_config,
-                         snapshot_parameters):
+                         optional_snapshot_parameters):
     return SnapshotDefinition()
 ```