This repository has been archived by the owner on Nov 9, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 88
Add VM_Name in config DB #1130
Labels
Comments
pshahzeb
pushed a commit
that referenced
this issue
Apr 6, 2017
1. Persisting VM name along with VM id and tenant id in config db when vm becomes a part of tenant. Updating the db manager api to accept list of tuple of vm id and name instead of just vm id 2. tenant object contains the list of tuple of vm id and names of VMs that are part of the tenant. Doing this saves trip to db while verifying params for tenant operations 3. Bumping the db version to 1.2. andling db schema upgrade from previous db version for vms table. Leaving the vm name None in db for VMs for which VM name couldn't be resolved during upgrade. Handling VM names which are None gracefully when printing them Testing: Updating related test cases for auth_data manager, vmdkops and admin cli Fixes #1130
pshahzeb
pushed a commit
that referenced
this issue
Apr 10, 2017
1. Persisting VM name along with VM id and tenant id in config db when vm becomes a part of tenant. Updating the db manager api to accept list of tuple of vm id and name instead of just vm id 2. tenant object contains the list of tuple of vm id and names of VMs that are part of the tenant. Doing this saves trip to db while verifying params for tenant operations 3. Bumping the db version to 1.2. andling db schema upgrade from previous db version for vms table. Leaving the vm name None in db for VMs for which VM name couldn't be resolved during upgrade. Handling VM names which are None gracefully when printing them Testing: Updating related test cases for auth_data manager, vmdkops and admin cli Fixes #1130
pshahzeb
pushed a commit
that referenced
this issue
Apr 10, 2017
1. Persisting VM name along with VM id and tenant id in config db when vm becomes a part of tenant. Updating the db manager api to accept list of tuple of vm id and name instead of just vm id 2. tenant object contains the list of tuple of vm id and names of VMs that are part of the tenant. Doing this saves trip to db while verifying params for tenant operations 3. Bumping the db version to 1.2. andling db schema upgrade from previous db version for vms table. Leaving the vm name None in db for VMs for which VM name couldn't be resolved during upgrade. Handling VM names which are None gracefully when printing them Testing: Updating related test cases for auth_data manager, vmdkops and admin cli Fixes #1130
pshahzeb
pushed a commit
that referenced
this issue
Apr 11, 2017
* Persisting VM name in config DB 1. Persisting VM name along with VM id and tenant id in config db when vm becomes a part of tenant. Updating the db manager api to accept list of tuple of vm id and name instead of just vm id 2. tenant object contains the list of tuple of vm id and names of VMs that are part of the tenant. Doing this saves trip to db while verifying params for tenant operations 3. Bumping the db version to 1.2. andling db schema upgrade from previous db version for vms table. Leaving the vm name None in db for VMs for which VM name couldn't be resolved during upgrade. Handling VM names which are None gracefully when printing them Testing: Updating related test cases for auth_data manager, vmdkops and admin cli Fixes #1130
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current Admin CLI logic is to persist the VM uuid and query VM name on demand. With shared multi-tenancy, user can run
vmdkops_admin vmgroup vm ls
and command must display VMs running on another ESX host as well.Proposed Solution:
Add VM_Name in DB. If FindVMByUuid() fails then use VM_Name in DB which may be stale in rare cases. Once we have property collector, this issue will go away.
Fix should be backward compatible i.e. for existing entries in DB with no VM_Name, it should log UUID.
Making it P0 since it is must-fix for cross-esx tenant configuration.
CC/ @shaominchen @lipingxue
The text was updated successfully, but these errors were encountered: