Rename "vm-group" to "vmgroup".

docs/blog/2016-10-28.md

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

docs/features/tenancy.md

@@ -4,35 +4,35 @@
 
 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 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.
+For the vSphere Docker Volume Service, Multi-tenancy is implemented by assigning a Datastore and VMs to a vmgroup.  A vmgroup can be granted access to create, delete or mount volumes on a specific datastore. VMs assigned to a vmgroup can then execute Docker volume APIs on an assigned datastores. Within a datastore multiple vmgroups can store their Docker volumes. A vmgroup cannot access volumes created by a different vmgroup i.e. vmgroups have their own independent namespace, even if vmgroups share datastores. VMs cannot be shared between vmgroups.
 
 Key attributes of tenancy:
 
 - vSphere Administrator can define group of one or more Docker Host (VM) as
-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. 
+vmgroup
+- Docker Host (VM) can be a member of one and only one vmgroup.
+- vSphere Administrator can grant vmgroup privileges & set resource consumption
+- Vmgroups can share the same underlying storage but preserve volume namespace isolation.
 limits at granularity of datastore.
 
 ## Admin CLI
 
-Vm-groups can be created and managed via the [Admin CLI](/user-guide/admin-cli/#Vm-group)
+Vmgroups can be created and managed via the [Admin CLI](/user-guide/admin-cli/#Vmgroup)
 
-## 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
+## Default vmgroup
+When a VM which does not belong to any vmgroup issues a request to vmdk_ops, this VM will be assumed to be in _DEFAULT vmgroup, and will get privileges
+associated with this vmgroup. \_DEFAULT vmgroup 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 vmgroup or modify privileges, thus locking
 down vmdk_ops to serve only explicitly configured VMs.
 
 ## Default privileges
-When a VM tries to manipulate volumes on a datastore which is not configured,  the system will use _DEFAULT privilege, which is created automatically 
-by system post install. This _DEFAULT privilege allows access to ANY datastore by default. An admin can edit or remove this record, thus locking down 
-the functionality to allow access only to explicitly configured datastores. 
+When a VM tries to manipulate volumes on a datastore which is not configured,  the system will use _DEFAULT privilege, which is created automatically
+by system post install. This _DEFAULT privilege allows access to ANY datastore by default. An admin can edit or remove this record, thus locking down
+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 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".
+When a VM addresses the volume using short notation (volume_name, without @datastore), all VMs in this vmgroup 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 vmgroup, 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 (vm-groups and privileges) 
+access control, we can create access control definition (vmgroups 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.
 
-# 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
+# vmgroup
+Create, delete, configure and show access control settings for a vmgroup.
+A vmgroup 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