Rename "tenant" to "vm-group" in related document and fix a merge con…

…flict.

docs/blog/2016-10-28.md

@@ -7,7 +7,7 @@ This release includes
 - Multi threaded ESX backend service
 - Numerous bug fixes
 
-## Tenancy
+## Vm-group
 - [Feature
   Overview](/features/tenancy)
 - [Tenancy

docs/features/tenancy.md

@@ -2,27 +2,27 @@
 
 # Tenancy
 
-Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers or "tenants." Tenants can be used to provide isolation between independent groups in shared environments, where multiple groups are using some common infrastructure i.e. compute, storage, network, etc. With tenancy, you can achieve isolation of resources of one tenant from other tenants. 
+Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers or "tenants." Tenants can be used to provide isolation between independent groups in shared environments, where multiple groups are using some common infrastructure i.e. compute, storage, network, etc. With tenancy, you can achieve isolation of resources of one tenant from other tenants.
 
-For the vSphere Docker Volume Service, Multi-tenancy is implemented by assigning a Datastore and VMs to a tenant.  A tenant can be granted access to create, delete or mount volumes on a specific datastore. VMs assigned to a tenant can then execute Docker volume APIs on an assigned datastores. Within a datastore multiple tenants can store their Docker volumes. A tenant cannot access volumes created by a different tenant i.e. tenants have their own independent namespace, even if tenants share datastores. VMs cannot be shared between tenants.
+For the vSphere Docker Volume Service, Multi-tenancy is implemented by assigning a Datastore and VMs to a vm-group.  A vm-group can be granted access to create, delete or mount volumes on a specific datastore. VMs assigned to a vm-group can then execute Docker volume APIs on an assigned datastores. Within a datastore multiple vm-groups can store their Docker volumes. A vm-group cannot access volumes created by a different vm-group i.e. vm-groups have their own independent namespace, even if vm-groups share datastores. VMs cannot be shared between vm-groups.
 
 Key attributes of tenancy:
 
 - vSphere Administrator can define group of one or more Docker Host (VM) as
-Tenant
-- Docker Host (VM) can be a member of one and only one Tenant.
-- vSphere Administrator can grant tenant privileges & set resource consumption
-- Tenants can share the same underlying storage but preserve volume namespace isolation. 
+vm-group
+- Docker Host (VM) can be a member of one and only one vm-group.
+- vSphere Administrator can grant vm-group privileges & set resource consumption
+- Vm-groups can share the same underlying storage but preserve volume namespace isolation. 
 limits at granularity of datastore.
 
 ## Admin CLI
 
-Tenants can be created and managed via the [Admin CLI](/user-guide/admin-cli/#tenant)
+Vm-groups can be created and managed via the [Admin CLI](/user-guide/admin-cli/#Vm-group)
 
-## Default tenant
-When a VM which does not belong to any tenant issues a request to vmdk_ops, this VM will be assumed to be in _DEFAULT tenant, and will get privileges 
-associated with this tenant. \_DEFAULT tenant will be automatically created by system post install, so by default vmdk_ops will support request from 
-any VM , thus maintaining backward compatibility and simplicity of installation.An admin can remove this tenant or modify privileges, thus locking 
+## Default vm-group
+When a VM which does not belong to any vm-group issues a request to vmdk_ops, this VM will be assumed to be in _DEFAULT vm-group, and will get privileges
+associated with this vm-group. \_DEFAULT vm-group will be automatically created by system post install, so by default vmdk_ops will support request from
+any VM , thus maintaining backward compatibility and simplicity of installation.An admin can remove this vm-group or modify privileges, thus locking
 down vmdk_ops to serve only explicitly configured VMs.
 
 ## Default privileges
@@ -31,8 +31,8 @@ by system post install. This _DEFAULT privilege allows access to ANY datastore b
 the functionality to allow access only to explicitly configured datastores. 
 
 ## Default datastore
-When a VM addresses the volume using short notation (volume_name, without @datastore), all VMs in this tenant will use default datastore to resolve short volume reference (volume_name will actually mean volume_name@default_datastore).
-If "default_datastore" is not set for a tenant, then datastore where the VM resides will be used as "default_datastore".
+When a VM addresses the volume using short notation (volume_name, without @datastore), all VMs in this vm-group will use default datastore to resolve short volume reference (volume_name will actually mean volume_name@default_datastore).
+If "default_datastore" is not set for a vm-group, then datastore where the VM resides will be used as "default_datastore".
 
 ## References
 

docs/misc/vmdkops-admin-cli-spec.md

@@ -11,7 +11,7 @@ All output from the admin cli defaults to human readable formats. It will be mad
 The majority of testing will be automated. We can ensure that parsing calls the right callbacks with
 the right information by generating representative input and mocking the callbacks to assert that
 the right information is parsed and delivered correctly. Additionally, and specifically for testing
-access control, we can create access control definition (tenants and privileges) 
+access control, we can create access control definition (vm-groups and privileges) 
 and then test that they act as expected by invoking vmdk_ops commmands on behalf of a fake VM.
 Unit
 tests for stateless logic can be fed mock input representing data from sidecar and the filesystem.
@@ -69,9 +69,9 @@ Examples:
 
 Note that on volume creation from docker, a policy name will be passed with a `-o` option.
 
-# tenant
-Create, delete, configure and show access control settings for a Tenant.
-A tenant is defined as a collection of VMs, so access control settings are assigned via a
+# vm-group
+Create, delete, configure and show access control settings for a vm-group.
+A vm-group is defined as a collection of VMs, so access control settings are assigned via a
 VM naming convention.
 *** The rest of section below needs rework as it represents obsolete "role" design ***
 An example will help clarify

docs/user-guide/faq.md

@@ -44,11 +44,11 @@ Tenancy changes in release 0.10 need a manual upgrade process enumerated below.
 
 ### How to know if auth-db upgrade is needed post install?
 
-After installing the new build, type command “tenant ls”
+After installing the new build, type command “vm-group ls”
 Check for failure to connect to auth DB.
 
 ```
-/usr/lib/vmware/vmdkops/bin/vmdkops_admin.py tenant ls
+/usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group ls
 Failed to connect auth DB(DB connection error /etc/vmware/vmdkops/auth-db)
 ```
 
@@ -63,30 +63,31 @@ The corresponding errors in the vmdk_ops.log file.
 
 ### How to handle the upgrade manually?
 
-#### Case 1: No tenant configured before
+#### Case 1: No vm-group configured before
 
-If no tenant has been configured, user just needs to delete the auth-db file
+If no vm-group has been configured, user just needs to delete the auth-db file
 
 Step 1: Remove  auth-db file at /etc/vmware/vmdkops/auth-db
 
 ``` 
 [root@localhost:/etc/vmware/vmdkops]rm /etc/vmware/vmdkops/auth-db
 ```
 
-Step 2: Verify “tenant ls” command
+Step 2: Verify “vm-group ls” command
 ``` 
-[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py tenant ls
-Uuid                                  Name      Description               Default_datastore  VM_list 
-------------------------------------  --------  ------------------------  -----------------  ------- 
-775888a6-6e98-4f41-9ff2-2ab12afd98de  _DEFAULT  This is a default tenant
+[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group ls
+Uuid                                  Name       Description                 Default_datastore  VM_list
+------------------------------------  ---------  --------------------------  -----------------  -------
+11111111-1111-1111-1111-111111111111  _DEFAULT   This is a default vm-group
+
 ```
 
 After this point, the manually upgrade is done, and tenancy operations will succeed.
 
-#### Case2:  Has tenant configured before
+#### Case2:  Has vm-group configured before
 Step 1: Backup data manually.
 
-Example below has a tenant ```tenant1``` with VM ```photon4``` assigned to this tenant and one volumes: vol1@datastore1 created.
+Example below has a vm-group ```vm-group1``` with VM ```photon-6``` assigned to this vm-group1 and one volumes: vol1@datastore1 created.
 
 ```
 root@photon-JQQBWNwG6 [ ~ ]# docker volume ls
@@ -102,56 +103,64 @@ Step 2: Move the auth-db file at /etc/vmware/vmdkops/auth-db
 [root@localhost:/etc/vmware/vmdkops]mv /etc/vmware/vmdkops/auth-db /etc/vmware/vmdkops/auth-db.backup.v10.upgrade
 ```
 
-Step 3: Verify “tenant ls” command, now only  ```_DEFAULT``` should be listed.
+Step 3: Verify “vm-group ls” command, now only  ```_DEFAULT``` should be listed.
 
 ``` 
-[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py tenant ls
-Uuid                                  Name      Description               Default_datastore  VM_list 
-------------------------------------  --------  ------------------------  -----------------  ------- 
-775888a6-6e98-4f41-9ff2-2ab12afd98de  _DEFAULT  This is a default tenant                             
+[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group ls
+Uuid                                  Name      Description                 Default_datastore  VM_list
+------------------------------------  --------  --------------------------  -----------------  -------
+11111111-1111-1111-1111-111111111111  _DEFAULT  This is a default vm-group
+
+
 ```
 
-Step 4: Recreate the tenant configuration with new name “new-tenant1” (associate the same VM photon4 to this new-tenant1), see the following example:
+Step 4: Recreate the vm-group configuration with new name “new-vm-group1” (associate the same VM photon-6 to this new-vm-group1), see the following example:
 
-***Note: Please DO NOT create the tenant with the old name “tenant1”!!!***
+***Note: Please DO NOT create the vm-group with the old name “vm-group1”!!!***
 
 ```
-[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py tenant create --name=new-tenant1  --vm-list=photon4
-tenant create succeeded
-[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py tenant access add --name=new-tenant1 --datastore=datastore1  --volume-maxsize=500MB --volume-totalsize=1GB --allow-create
-tenant access add succeeded
- 
-[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py tenant ls
-Uuid                                  Name         Description               Default_datastore  VM_list 
-------------------------------------  -----------  ------------------------  -----------------  ------- 
-775888a6-6e98-4f41-9ff2-2ab12afd98de  _DEFAULT     This is a default tenant                             
-d5964623-f4bd-4fa6-af4f-b7fa7f51ba5e  new-tenant1                            datastore1         photon4 
+[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group create --name=new-vm-group1  --vm-list=photon-6
+vm-group create succeeded
+[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group access add --name=new-vm-group1 --datastore=datastore1  --volume-maxsize=500MB --volume-totalsize=1GB --allow-create
+vm-group access add succeeded
+
+[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group vm rm --name=new-vm-group1 --vm-list=photon7
+vm-group vm rm succeeded
+[root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vm-group ls
+Uuid                                  Name           Description                 Default_datastore  VM_list
+------------------------------------  -------------  --------------------------  -----------------  --------
+11111111-1111-1111-1111-111111111111  _DEFAULT       This is a default vm-group
+5c0927fb-86b5-4034-87db-8bdfa24018d4  new-vm-group1                              datastore1         photon-6
+
+
+
 ```
 
-Step 4: Run “docker volume ls” from VM “photon4”,  volume which belongs to “tenant1” which was created before will not be visible
+Step 4: Run “docker volume ls” from VM “photon-6”,  volume which belongs to “vm-group1” which was created before will not be visible
 ``` 
 root@photon-JQQBWNwG6 [ ~ ]# docker volume ls
 DRIVER              VOLUME NAME
 ```
 
-Step 5: Run “docker volume create”  to create a new volume “new-tenant1-vol1” and run “docker volume ls”,   should only able to see this volume which was just created
+Step 5: Run “docker volume create”  to create a new volume “new-vol1” and run “docker volume ls”,   should only able to see this volume which was just created
 ``` 
-root@photon-JQQBWNwG6 [ ~ ]# docker volume create --driver=vsphere --name=new-tenant1-vol1 -o size=100MB
-new-tenant1-vol1
-root@photon-JQQBWNwG6 [ ~ ]# docker volume ls
+root@photon-KwqUODFXp [ ~ ]# docker volume create --driver=vsphere --name=new-vol1 -o size=100MB
+new-vol1
+root@photon-KwqUODFXp [ ~ ]# docker volume ls
 DRIVER              VOLUME NAME
-vmdk                new-tenant1-vol1@datastore1
+vsphere             new-vol1@datastore1
 ```
 
 Volume “vol1” which was created before still exists, and can be seen from the following AdminCLI command
 
 ```
 [root@localhost:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py ls
-Volume            Datastore   Created By VM  Created                   Attached To VM  Policy  Capacity  Used      Disk Format  Filesystem Type  Access      Attach As              
-----------------  ----------  -------------  ------------------------  --------------  ------  --------  --------  -----------  ---------------  ----------  ---------------------- 
-new-tenant1-vol1  datastore1  photon4        Mon Aug 29 09:17:01 2016  detached        N/A     100.00MB  13.00MB   thin         ext4             read-write  independent_persistent 
-vol1              datastore1  photon4        Mon Aug 29 09:09:18 2016  detached        N/A     100.00MB  100.00MB  thin         ext4             read-write  independent_persistent 
+Volume    Datastore   Created By VM  Created                   Attached To VM (name/uuid)  Policy  Capacity  Used  Disk Format  Filesystem Type  Access      Attach As
+--------  ----------  -------------  ------------------------  --------------------------  ------  --------  ----  -----------  ---------------  ----------  ----------------------
+vol1      datastore1  photon-6       Sun Sep 11 07:30:47 2016  detached                    N/A     100MB     13MB  thin         ext4             read-write  independent_persistent
+new-vol1  datastore1  photon-6       Sun Sep 11 08:03:56 2016  detached                    N/A     100MB     13MB  thin         ext4             read-write  independent_persistent
+
 ```
 
-Step6: Manually copy the data from backup to the new volume "new-tenant1-vol1@datastore1". 
-The path which stores this new volume is "/vmfs/volumes/datastore1/dockvols/new-tenant1".
+Step6: Manually copy the data from backup to the new volume "new-vol1@datastore1".
+The path which stores this new volume is "/vmfs/volumes/datastore1/dockvols/new-vm-group1".