As we have been documenting hamlet, it feels more logical to use tenant-cmdb as the name of the repo containing the tenant and account information.
Current Behavior
Currently the default cmdb expected is accounts-cmdb.
Possible Solution
At a minimum, the default value in setContext.sh needs to be changed.
This will break any clients where the default value has been assumed so before releasing the change, we will need to explicitly set ACCOUNT_CONFIG_REPO for all clients.
Given this, I wonder if the default should just be removed altogether to make the setting explicit everywhere.
NOTE: The default behaviour of github is to serve renamed repos by former names until the former names are reused. So renaming the repo to tenant-cmdb BEFORE making the change shouldn't break anything.
While constructTree.sh permits the accounts-cmdb to be split across two repos (config and infrastructure), this has never been done for a customer and adds additional complexity. I'd suggest removing it as part of this change.
Context
Making things as logical and obvious as possible should be a goal of Hamlet. It reduces the learning curve for new customers, and makes the framework easier to work with.
Expected Behavior
As we have been documenting hamlet, it feels more logical to use
tenant-cmdb
as the name of the repo containing the tenant and account information.Current Behavior
Currently the default cmdb expected is
accounts-cmdb
.Possible Solution
At a minimum, the default value in
setContext.sh
needs to be changed.This will break any clients where the default value has been assumed so before releasing the change, we will need to explicitly set ACCOUNT_CONFIG_REPO for all clients.
Given this, I wonder if the default should just be removed altogether to make the setting explicit everywhere.
NOTE: The default behaviour of github is to serve renamed repos by former names until the former names are reused. So renaming the repo to
tenant-cmdb
BEFORE making the change shouldn't break anything.While
constructTree.sh
permits the accounts-cmdb to be split across two repos (config and infrastructure), this has never been done for a customer and adds additional complexity. I'd suggest removing it as part of this change.Context
Making things as logical and obvious as possible should be a goal of Hamlet. It reduces the learning curve for new customers, and makes the framework easier to work with.