chore(ci): updating branch reference from master to develop(HEAD) (#384) (#385)

* chore(ci): updating branch reference from master to develop(HEAD) (#384)


Signed-off-by: mittachaitu <sai.chaithanya@mayadata.io>
Co-authored-by: sai chaithanya <sai.chaithanya@mayadata.io>

.github/workflows/build.yml

@@ -17,7 +17,7 @@ on:
   create:
   push:
     branches:
-    - master
+    - develop
     - 'v*'
     paths-ignore:
     - 'docs/**'
@@ -148,7 +148,7 @@ jobs:
         run: |
           BRANCH="${GITHUB_REF##*/}"
           CI_TAG=${BRANCH#v}-ci
-          if [ ${BRANCH} = "master" ]; then
+          if [ ${BRANCH} = "develop" ]; then
             CI_TAG="ci"
           fi
           echo "TAG=${CI_TAG}" >> $GITHUB_ENV

.github/workflows/chart-lint-test.yml

@@ -5,12 +5,12 @@ on:
     paths:
       - 'deploy/helm/**'
     branches:
-      - master
+      - develop
   pull_request:
     paths:
       - 'deploy/helm/**'
     branches:
-      - master
+      - develop
 
 jobs:
   lint-test:

.github/workflows/pull_request.yml

@@ -23,8 +23,8 @@ on:
       - 'changelogs/**'
       - '*.md'
     branches:
-      # on pull requests to master and release branches
-      - master
+      # on pull requests to develop and release branches
+      - develop
       - 'v*'
 
 jobs:

.github/workflows/release-charts.yml

@@ -5,7 +5,7 @@ on:
     paths:
       - 'deploy/helm/**'
     branches:
-      - master
+      - develop
 
 jobs:
   release:
@@ -36,7 +36,7 @@ jobs:
             echo "Commiting changes to deploy/helm/charts/crds"
             git add deploy/helm/charts/crds
             git commit -s -m 'chore(crd): add auto generated crds to helm release'
-            git push origin master
+            git push origin develop
           fi
 
       - name: Run chart-releaser

Adopters.md

@@ -7,9 +7,9 @@ The list of organizations that have publicly shared the usage of ZFS-LocalPV.
 
 | Organization | Stateful Workloads | Success Story |
 | :--- | :--- | :--- |
-| [IDNT](https://idnt.net/) | Elasticsearch, RabbitMQ, KubeVirt, Prometheus, YugabyteDB, Couchbase, MySQL | [English](https://github.com/openebs/openebs/blob/master/adopters/idnt/README.md) |
-| [Optoro](https://www.optoro.com/) | PostgreSQL, MySQL, Apache Kafka, Redis, ElasticSearch, Prometheus, Thanos | [English](https://github.com/openebs/openebs/blob/master/adopters/optoro/README.md) |
-| [Zeta Associates](https://www.zai.com/) | Elasticsearch, MariaDB, MinIO, PostgreSQL, Prometheus, Kafka, Cassandra | [English](https://github.com/openebs/openebs/blob/master/adopters/zetaassociates/README.md) |
+| [IDNT](https://idnt.net/) | Elasticsearch, RabbitMQ, KubeVirt, Prometheus, YugabyteDB, Couchbase, MySQL | [English](https://github.com/openebs/openebs/blob/HEAD/adopters/idnt/README.md) |
+| [Optoro](https://www.optoro.com/) | PostgreSQL, MySQL, Apache Kafka, Redis, ElasticSearch, Prometheus, Thanos | [English](https://github.com/openebs/openebs/blob/HEAD/adopters/optoro/README.md) |
+| [Zeta Associates](https://www.zai.com/) | Elasticsearch, MariaDB, MinIO, PostgreSQL, Prometheus, Kafka, Cassandra | [English](https://github.com/openebs/openebs/blob/HEAD/adopters/zetaassociates/README.md) |
 
 
 
@@ -18,6 +18,6 @@ The list of users that have publicly shared the usage of ZFS-LocalPV.
 
 | User | Stateful Workloads | Success Story |
 | :--- | :--- | :--- |
-| [Art Win](https://github.com/artw) | Graylog, Zabbix, Authelia, Guacamole (Elastic, MySQL, MongoDB, Redis) | [English](https://github.com/openebs/openebs/blob/master/adopters/users/artw/README.md)  |
-| [Mark V.](https://github.com/mikroskeem) | Concourse CI, Mattermost, Minio, Few game servers, Bunch of micro services | [English](https://github.com/openebs/openebs/blob/master/adopters/users/mikroskeem/README.md)  | 
-| [Steve Fan](https://github.com/stevefan1999-personal) | [Agones - Game Servers on K8s](https://agones.dev/site/) | [English](https://github.com/openebs/openebs/blob/master/adopters/users/stevefan/README.md)  | 
+| [Art Win](https://github.com/artw) | Graylog, Zabbix, Authelia, Guacamole (Elastic, MySQL, MongoDB, Redis) | [English](https://github.com/openebs/openebs/blob/HEAD/adopters/users/artw/README.md)  |
+| [Mark V.](https://github.com/mikroskeem) | Concourse CI, Mattermost, Minio, Few game servers, Bunch of micro services | [English](https://github.com/openebs/openebs/blob/HEAD/adopters/users/mikroskeem/README.md)  | 
+| [Steve Fan](https://github.com/stevefan1999-personal) | [Agones - Game Servers on K8s](https://agones.dev/site/) | [English](https://github.com/openebs/openebs/blob/HEAD/adopters/users/stevefan/README.md)  | 

CONTRIBUTING.md

@@ -5,7 +5,7 @@ ZFS LocalPV uses the standard GitHub pull requests process to review and accept
 * If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute).
 * If you have documentation improvement ideas, go ahead and create a pull request. See [Pull Request checklist](#pull-request-checklist)
 * If you would like to make code contributions, please start with [Setting up the Development Environment](#setting-up-your-development-environment).
-* If you would like to work on something more involved, please connect with the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community)
+* If you would like to work on something more involved, please connect with the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/HEAD/community)
 
 ## Steps to Contribute
 
@@ -14,7 +14,7 @@ ZFS-LocalPV is an Apache 2.0 Licensed project and all your commits should be sig
 * Find an issue to work on or create a new issue. The issues are maintained at [zfs-localpv/issues](https://github.com/openebs/zfs-localpv/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/zfs-localpv/labels/good%20first%20issue).
 * Claim your issue by commenting your intent to work on it to avoid duplication of efforts.
 * Fork the repository on GitHub and clone.
-* Create a branch from where you want to base your work (usually master).
+* Create a branch from where you want to base your work (usually develop).
 * Make your changes. If you are working on code contributions, please see [Setting up the Development Environment](#setting-up-your-development-environment).
 * Relevant coding style guidelines are the [Go Code Review Comments](https://code.google.com/p/go-wiki/wiki/CodeReviewComments) and the _Formatting and style_ section of Peter Bourgon's [Go: Best Practices for Production Environments](http://peter.bourgon.org/go-in-production/#formatting-and-style).
 * Commit your changes by making sure the commit messages convey the need and notes about the commit.
@@ -23,19 +23,19 @@ ZFS-LocalPV is an Apache 2.0 Licensed project and all your commits should be sig
 
 
 ## Pull Request Checklist
-* Rebase to the current master branch before submitting your pull request.
+* Rebase to the current develop branch before submitting your pull request.
 * Commits should be as small as possible. Each commit should follow the checklist below:
   - For code changes, add tests relevant to the fixed bug or new feature. 
   - Before committing your code, make sure you have run `make format` and `make manifests`, to format the code and autogenerate the CRDs yaml.
   - Pass the compile and tests - includes spell checks, formatting, etc.
-  - Commit header (first line) should convey what changed and it should follow the commit [guideline](https://github.com/openebs/openebs/blob/master/contribute/git-commit-message.md)
+  - Commit header (first line) should convey what changed and it should follow the commit [guideline](https://github.com/openebs/openebs/blob/HEAD/contribute/git-commit-message.md)
   - Commit body should include details such as why the changes are required and how the proposed changes help
   - DCO Signed  
-* If your PR is not getting reviewed or you need a specific person to review it, please reach out to the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community)
+* If your PR is not getting reviewed or you need a specific person to review it, please reach out to the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/HEAD/community)
 
 ## Sign your work
 
-We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS projects. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please read [dcofile](https://github.com/openebs/openebs/blob/master/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message:
+We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS projects. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please read [dcofile](https://github.com/openebs/openebs/blob/HEAD/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message:
 
 ````
   Signed-off-by: Random J Developer <random@developer.example.org>
@@ -62,4 +62,4 @@ This project is implemented using Go and uses the standard golang tools for deve
 
 For setting up a Development environment on your local host, see the detailed instructions [here](./docs/developer-setup.md).
 
-The ZFS LocalPV design document is available [here](https://github.com/openebs/openebs/blob/master/contribute/design/1.x/csi/20190805-csi-zfspv-volume-provisioning.md).
+The ZFS LocalPV design document is available [here](https://github.com/openebs/openebs/blob/HEAD/contribute/design/1.x/csi/20190805-csi-zfspv-volume-provisioning.md).

GOVERNANCE.md

@@ -1,2 +1,2 @@
 This is a OpenEBS sub project and abides by the
-[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md).
+[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/HEAD/GOVERNANCE.md).

README.md

@@ -1,5 +1,5 @@
 # OpenEBS ZFS CSI Driver
-[![Build Status](https://travis-ci.org/openebs/zfs-localpv.svg?branch=master)](https://travis-ci.org/openebs/zfs-localpv)
+[![Build Status](https://github.com/openebs/zfs-localpv/actions/workflows/build.yml/badge.svg)](https://github.com/openebs/zfs-localpv/actions/workflows/build.yml)
 [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fopenebs%2Fzfs-localpv.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fopenebs%2Fzfs-localpv?ref=badge_shield)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3523/badge)](https://bestpractices.coreinfrastructure.org/en/projects/3523)
 [![Slack](https://img.shields.io/badge/chat!!!-slack-ff1493.svg?style=flat-square)](https://kubernetes.slack.com/messages/openebs/)
@@ -84,7 +84,7 @@ errors: No known data errors
 
 Configure the custom topology keys (if needed). This can be used for many purposes like if we want to create the PV on nodes in a particuler zone or building. We can label the nodes accordingly and use that key in the storageclass for taking the scheduling decesion:
 
-https://github.com/openebs/zfs-localpv/blob/master/docs/faq.md#6-how-to-add-custom-topology-key
+https://github.com/openebs/zfs-localpv/blob/HEAD/docs/faq.md#6-how-to-add-custom-topology-key
 
 ### Installation
 
@@ -236,7 +236,7 @@ Please note that the provisioner name for ZFS driver is "zfs.csi.openebs.io", we
 
 ##### Scheduler
  
-The ZFS driver has its own scheduler which will try to distribute the PV across the nodes so that one node should not be loaded with all the volumes. Currently the driver supports two scheduling algorithms: VolumeWeighted and CapacityWeighted, in which it will try to find a ZFS pool which has less number of volumes provisioned in it or less capacity of volume provisioned out of a pool respectively, from all the nodes where the ZFS pools are available. To know about how to select scheduler via storage-class See [this](https://github.com/openebs/zfs-localpv/blob/master/docs/storageclasses.md#storageclass-with-k8s-scheduler).
+The ZFS driver has its own scheduler which will try to distribute the PV across the nodes so that one node should not be loaded with all the volumes. Currently the driver supports two scheduling algorithms: VolumeWeighted and CapacityWeighted, in which it will try to find a ZFS pool which has less number of volumes provisioned in it or less capacity of volume provisioned out of a pool respectively, from all the nodes where the ZFS pools are available. To know about how to select scheduler via storage-class See [this](https://github.com/openebs/zfs-localpv/blob/HEAD/docs/storageclasses.md#storageclass-with-k8s-scheduler).
 Once it is able to find the node, it will create a PV for that node and also create a ZFSVolume custom resource for the volume with the NODE information. The watcher for this ZFSVolume
 CR will get all the information for this object and creates a ZFS dataset(zvol) with the given ZFS property on the mentioned node.
 

RELEASE.md

@@ -20,7 +20,7 @@ Once all the above tests are completed, a main release tagged image is published
 
 zfs-localpv is released as container image with versioned tag.
 
-Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `master`. Name of the branch should follow the naming convention of `v.0.7.x` if release is for 0.7.0.
+Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `develop`. Name of the branch should follow the naming convention of `v.0.7.x` if release is for 0.7.0.
 
 Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder, if release branch is `v0.7.x` then folder will be `changelogs/v0.7.x`.
 
@@ -33,7 +33,7 @@ Images are published at following location :
 https://quay.io/repository/openebs/zfs-driver?tab=tags
 https://hub.docker.com/r/openebs/zfs-driver/tags
 
-Once a release is created, update the release description with the changelog mentioned in `changelog/v0.7.x`. Once the changelogs are updated in the release, the repo owner needs to create a PR to `master` with the following details:
+Once a release is created, update the release description with the changelog mentioned in `changelog/v0.7.x`. Once the changelogs are updated in the release, the repo owner needs to create a PR to `develop` with the following details:
 1. update the changelog from `changelog/v0.7.x` to `zfs-localpv/CHANGELOG.md`
 2. If a release is not an RC tag then PR should include the changes to remove `changelog/v0.7.x` folder.
 3. If a release is an RC tag then PR should include the changes to remove the changelog from `changelog/v0.7.x` which are already mentioned in `zfs-localpv/CHANGELOG.md` as part of step number 1.

buildscripts/push

@@ -72,7 +72,7 @@ fi
 # set the tag CI (fixed) and build tags.
 BUILD_TAG="${CURRENT_BRANCH}-${BUILD_ID}"
 CI_TAG="${CURRENT_BRANCH}-ci"
-if [ ${CURRENT_BRANCH} = "master" ]; then
+if [ ${CURRENT_BRANCH} = "develop" ]; then
   CI_TAG="ci"
 fi
 
@@ -106,7 +106,7 @@ then
   # Push CI tagged image - :ci or :branch-ci
   TagAndPushImage "${DIMAGE}" "${CI_TAG}"
 
-  # Push unique tagged image - :master-<uuid> or :branch-<uuid>
+  # Push unique tagged image - :develop-<uuid> or :branch-<uuid>
   # This unique/build image will be pushed to corresponding ci repo.
   TagAndPushImage "${DIMAGE}-ci" "${BUILD_TAG}"
 

ct.yaml

@@ -1,6 +1,6 @@
 # See https://github.com/helm/chart-testing#configuration
 remote: origin
-target-branch: master
+target-branch: develop
 chart-dirs:
   - deploy/helm
 helm-extra-args: --timeout=500s

deploy/helm/charts/Chart.yaml

@@ -1,7 +1,7 @@
 apiVersion: v2
 name: zfs-localpv
 description: Helm chart for CSI Driver for dynamic provisioning of ZFS Persistent Local Volumes. For instructions on how to use this helm chart, see - https://openebs.github.io/zfs-localpv/
-version: 1.9.6
+version: 1.9.7
 appVersion: 1.9.1
 icon: https://raw.githubusercontent.com/cncf/artwork/master/projects/openebs/icon/color/openebs-icon-color.png
 home: http://www.openebs.io/

deploy/helm/charts/README.md

@@ -3,7 +3,7 @@
 
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 ![Chart Lint and Test](https://github.com/openebs/zfs-localpv/workflows/Chart%20Lint%20and%20Test/badge.svg)
-![Release Charts](https://github.com/openebs/zfs-localpv/workflows/Release%20Charts/badge.svg?branch=master)
+![Release Charts](https://github.com/openebs/zfs-localpv/workflows/Release%20Charts/badge.svg?branch=develop)
 
 A Helm chart for openebs zfs localpv provisioner. This chart bootstraps OpenEBS ZFS LocalPV provisioner deployment on a [Kubernetes](http://kubernetes.io) cluster using the  [Helm](https://helm.sh) package manager.
 

docs/backup-restore.md

@@ -53,7 +53,7 @@ We have to install the velero 1.5 or later version for ZFS-LocalPV.
 Deploy the minio for storing the backup :-
 
 ```
-$ kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/master/deploy/sample/minio.yaml
+$ kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/develop/deploy/sample/minio.yaml
 ```
 
 The above minio uses tmp directory inside the pod to store the data, so when restart happens, the backed up data will be gone. We can change the above yaml to use persistence storage to store the data so that we can persist the data after restart.

docs/developer-setup-examples.md

@@ -15,7 +15,7 @@ sudo dpkg -i minikube_1.9.2-0_amd64.deb
 sudo minikube start --driver=none
 sudo chown -R $USER $HOME/.kube $HOME/.minikube
 
-kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/master/deploy/zfs-operator.yaml
+kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/develop/deploy/zfs-operator.yaml
 kubectl get pods -n kube-system -l role=openebs-zfs
 
 export OPENEBS_NAMESPACE=openebs

docs/developer-setup.md

@@ -25,7 +25,7 @@ git clone https://github.com/$user/zfs-localpv.git
 cd zfs-localpv
 git remote add upstream https://github.com/openebs/zfs-localpv.git
 
-# Never push to upstream master
+# Never push to upstream develop
 git remote set-url --push upstream no_push
 
 # Confirm that your remotes make sense:
@@ -44,15 +44,15 @@ Open a terminal on your local host. Change directory to the zfs-localpv fork roo
 $ cd zfs-localpv
 ```
 
- Checkout the master branch.
+ Checkout the develop branch.
 
  ```sh
- $ git checkout master
- Switched to branch 'master'
- Your branch is up-to-date with 'origin/master'.
+ $ git checkout develop
+ Switched to branch 'develop'
+ Your branch is up-to-date with 'origin/develop'.
  ```
 
- Recall that origin/master is a branch on your remote GitHub repository.
+ Recall that origin/develop is a branch on your remote GitHub repository.
  Make sure you have the upstream remote openebs/zfs-localpv by listing them.
 
  ```sh
@@ -68,43 +68,43 @@ $ cd zfs-localpv
  ```sh
  $ git remote add upstream https://github.com/openebs/zfs-localpv.git
  ```
- Fetch all the changes from the upstream master branch.
+ Fetch all the changes from the upstream develop branch.
 
  ```sh
- $ git fetch upstream master
+ $ git fetch upstream develop
  remote: Counting objects: 141, done.
  remote: Compressing objects: 100% (29/29), done.
  remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66
  Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done.
  Resolving deltas: 100% (79/79), done.
  From github.com:openebs/zfs-localpv
-   * branch            master     -> FETCH_HEAD
+   * branch            develop     -> FETCH_HEAD
  ```
 
- Rebase your local master with the upstream/master.
+ Rebase your local develop with the upstream/develop.
 
  ```sh
- $ git rebase upstream/master
+ $ git rebase upstream/develop
  First, rewinding head to replay your work on top of it...
- Fast-forwarded master to upstream/master.
+ Fast-forwarded develop to upstream/develop.
  ```
- This command applies all the commits from the upstream master to your local master.
+ This command applies all the commits from the upstream develop to your local develop.
 
  Check the status of your local branch.
 
  ```sh
  $ git status
- On branch master
- Your branch is ahead of 'origin/master' by 38 commits.
+ On branch develop
+ Your branch is ahead of 'origin/develop' by 38 commits.
  (use "git push" to publish your local commits)
  nothing to commit, working directory clean
  ```
- Your local repository now has all the changes from the upstream remote. You need to push the changes to your own remote fork which is origin master.
+ Your local repository now has all the changes from the upstream remote. You need to push the changes to your own remote fork which is origin develop.
 
- Push the rebased master to origin master.
+ Push the rebased develop to origin develop.
 
  ```sh
- $ git push origin master
+ $ git push origin develop
  Username for 'https://github.com': $user
  Password for 'https://$user@github.com':
  Counting objects: 223, done.
@@ -112,16 +112,16 @@ $ cd zfs-localpv
  Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done.
  Total 69 (delta 53), reused 47 (delta 31)
  To https://github.com/$user/zfs-localpv.git
- 8e107a9..5035fa1  master -> master
+ 8e107a9..5035fa1  develop -> develop
  ```
 
 ### Contributing to a feature or bugfix. 
 
-Always start with creating a new branch from master to work on a new feature or bugfix. Your branch name should have the format XX-descriptive where XX is the issue number you are working on followed by some descriptive text. For example:
+Always start with creating a new branch from develop to work on a new feature or bugfix. Your branch name should have the format XX-descriptive where XX is the issue number you are working on followed by some descriptive text. For example:
 
  ```sh
- $ git checkout master
- # Make sure the master is rebased with the latest changes as described in previous step.
+ $ git checkout develop
+ # Make sure the develop is rebased with the latest changes as described in previous step.
  $ git checkout -b 1234-fix-developer-docs
  Switched to a new branch '1234-fix-developer-docs'
  ```
@@ -145,7 +145,7 @@ Happy Hacking!
 ```sh
 # While on your myfeature branch (see above)
 git fetch upstream
-git rebase upstream/master
+git rebase upstream/develop
 ```
 
 While you rebase your changes, you must resolve any conflicts that might arise and build and test your changes using the above steps. 

docs/faq.md

@@ -14,7 +14,7 @@ Go to each node and create the ZFS Pool, which will be used for provisioning the
 Once ZFS POOL is created we can install OpenEBS ZFS driver by running the following command.
 
 ```
-kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/master/deploy/zfs-operator.yaml
+kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/develop/deploy/zfs-operator.yaml
 ```
 
 Verify that the ZFS driver Components are installed and running using below command :
@@ -37,7 +37,7 @@ openebs-zfs-node-twmx8     2/2     Running   0          5h28m
 
 ### 3. How to upgrade the driver to newer version
 
-Follow the instructions here https://github.com/openebs/zfs-localpv/tree/master/upgrade.
+Follow the instructions here https://github.com/openebs/zfs-localpv/tree/develop/upgrade.
 
 ### 4. ZFS Pools are there on certain nodes only, how can I create the storage class.
 

docs/grafana-dashboard.md

@@ -105,7 +105,7 @@ prometheus-operator-prometheus-node-exporter   ClusterIP   10.98.128.115   <none
 - Paste the below json and Click on Load
 
   ```
-  https://raw.githubusercontent.com/openebs/zfs-localpv/master/deploy/sample/grafana-dashboard.json
+  https://raw.githubusercontent.com/openebs/zfs-localpv/develop/deploy/sample/grafana-dashboard.json
   ```
 - Select datasource as Prometheus and Import it.
 
@@ -121,7 +121,7 @@ This dashboard exposes below metrics
 
 The "ZFS-LocalPV" dashboard will look like this :-
 
-![Grafana](https://github.com/openebs/zfs-localpv/blob/master/deploy/sample/vol-stats.png)
+![Grafana](https://github.com/openebs/zfs-localpv/blob/develop/deploy/sample/vol-stats.png)
 
 ## References:
 - https://helm.sh/docs/intro/install/

e2e-tests/experiments/upgrade-zfs-localpv/README.md

@@ -1,6 +1,6 @@
 ## About this experiment
 
-This experiment upgrades the zfs-localpv driver components from any previous version to the latest desired stable version or to the master branch ci images. 
+This experiment upgrades the zfs-localpv driver components from any previous version to the latest desired stable version or to the develop branch ci images. 
 
 ## Supported platforms:
 
@@ -47,4 +47,4 @@ To get the test-case result, get the corresponding e2e custom-resource `e2eresul
 kubectl get e2er
 kubectl get e2er upgrade-zfs-localpv -n e2e --no-headers -o custom-columns=:.spec.testStatus.phase
 kubectl get e2er upgrade-zfs-localpv -n e2e --no-headers -o custom-columns=:.spec.testStatus.result
-```
+```

e2e-tests/experiments/upgrade-zfs-localpv/run_e2e_test.yml

@@ -21,7 +21,7 @@ spec:
             value: default
 
             ## Give the versioned branch name for zfs_localpv provisioner from openebs/zfs-localpv repo
-            ## for e.g. (v1.4.x , v1.5.x  OR  master)
+            ## for e.g. (v1.4.x , v1.5.x  OR  develop)
           - name: TO_VERSION_ZFS_BRANCH
             value: ''
 
@@ -38,4 +38,4 @@ spec:
             value: 'openebs'
 
         command: ["/bin/bash"]
-        args: ["-c", "ansible-playbook ./e2e-tests/experiments/upgrade-zfs-localpv/test.yml -i /etc/ansible/hosts -v; exit 0"]
+        args: ["-c", "ansible-playbook ./e2e-tests/experiments/upgrade-zfs-localpv/test.yml -i /etc/ansible/hosts -v; exit 0"]

e2e-tests/experiments/upgrade-zfs-localpv/test.yml

@@ -66,7 +66,7 @@
             ## under `zfs.openebs.io` from v0.6 release.
           - name: Apply the new CRDs for zfs-LocalPV 
             shell: >
-              kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/master/upgrade/crd.yaml
+              kubectl apply -f https://raw.githubusercontent.com/openebs/zfs-localpv/develop/upgrade/crd.yaml
             args:
               executable: /bin/bash
             register: new_crds
@@ -76,7 +76,7 @@
             ## apiversion to `zfs.openebs.io`. Previously this was `openebs.io`.
           - name: Download the Upgrade script for creating new CRs with apiversion as `zfs.openebs.io`
             get_url:  
-              url: https://raw.githubusercontent.com/openebs/zfs-localpv/master/upgrade/upgrade.sh
+              url: https://raw.githubusercontent.com/openebs/zfs-localpv/develop/upgrade/upgrade.sh
               dest: ./upgrade.sh
               force: yes
             register: result
@@ -190,7 +190,7 @@
 
           - name: Download the cleanup script for removing the resources with old CRs and delete old CRDs
             get_url:  
-              url: https://raw.githubusercontent.com/openebs/zfs-localpv/master/upgrade/cleanup.sh
+              url: https://raw.githubusercontent.com/openebs/zfs-localpv/develop/upgrade/cleanup.sh
               dest: ./cleanup.sh
               force: yes
             register: result
@@ -219,4 +219,4 @@
         ## Record SOT (start of test) in e2e result e2e-cr (e2e-custom-resource)
         - include_tasks: /e2e-tests/hack/update_e2e_result_resource.yml
           vars:
-            status: 'EOT' 
+            status: 'EOT' 

e2e-tests/experiments/zfs-localpv-provisioner/run_e2e_test.yml

@@ -23,10 +23,10 @@ spec:
 
             # This test will download the zfs-localpv operator file from this branch.
             # Change the env value according to versioned branch name for zfs-localpv provisioner
-            # from openebs/zfs-localpv repo. for e.g. (v1.4.x , v1.5.x  OR  master)
-            # by default test-specific value of `ZFS_BRANCH` is master.
+            # from openebs/zfs-localpv repo. for e.g. (v1.4.x , v1.5.x  OR  develop)
+            # by default test-specific value of `ZFS_BRANCH` is develop.
           - name: ZFS_BRANCH  
-            value: 'master'
+            value: 'develop'
 
             # After v1.5.0 in each branch of openebs/zfs-localpv repo zfs-localpv driver image is set to
             # `ci` tag `openebs/zfs-driver:ci`. Give the full image name here with desired image tag to replace
@@ -126,4 +126,4 @@ spec:
             value: '4k'
 
         command: ["/bin/bash"]
-        args: ["-c", "ansible-playbook ./e2e-tests/experiments/zfs-localpv-provisioner/test.yml -i /etc/ansible/hosts -v; exit 0"]
+        args: ["-c", "ansible-playbook ./e2e-tests/experiments/zfs-localpv-provisioner/test.yml -i /etc/ansible/hosts -v; exit 0"]