SDP-294
Open
Deprecate sdp_hosts.cfg in favor of HelixTopology.cfg.
The sdp_sync.sh ("tight ship enforcer" script) and the
global_replica_status.sh script use the sdp_hosts.cfg file,
but should be retooled to use the HelixTopology.cfg file
instead of the sdp_hosts.cfg.
Some concerns with doing this:
* The sdp_hosts.cfg file is simpler and less intimidating,
and has a narrow scope. Despite some overlap, it may be
worth keeping it as a separate file from the more comprehensive
but possibly daunting HelixTopology.cfg.
* Presently sdp_hosts.cfg is a pre-requisite to running hms_ts_setup.sh.
* We need to decide whether to make it backward-compatible,
e.g. support both sdp_hosts.cfg and HelixTopology.cfg,
deferring to HelixTopology.cfg if it exists. That would
make it more complex and potentially confusing, but could
simplify the upgrade process for customers using sdp_hosts.cfg
but not doing the full HMS thing yet.
The sdp_sync.sh ("tight ship enforcer" script) and the
global_replica_status.sh script use the sdp_hosts.cfg file,
but should be retooled to use the HelixTopology.cfg file
instead of the sdp_hosts.cfg.
Some concerns with doing this:
* The sdp_hosts.cfg file is simpler and less intimidating,
and has a narrow scope. Despite some overlap, it may be
worth keeping it as a separate file from the more comprehensive
but possibly daunting HelixTopology.cfg.
* Presently sdp_hosts.cfg is a pre-requisite to running hms_ts_setup.sh.
* We need to decide whether to make it backward-compatible,
e.g. support both sdp_hosts.cfg and HelixTopology.cfg,
deferring to HelixTopology.cfg if it exists. That would
make it more complex and potentially confusing, but could
simplify the upgrade process for customers using sdp_hosts.cfg
but not doing the full HMS thing yet.
- Status
- Open
- Project
- perforce-software-sdp
- Severity
- C
- Reported By
- C. Thomas Tyler
- Reported Date
- 7 years ago
- Modified By
- C. Thomas Tyler
- Modified Date
- 7 years ago
- Owned By
- tom_tyler
- Component
- hms
- Type
- Feature
Yes I think this is a good idea to have one file. The reason to keep it separate is if you want to keep the idea of SDP and HMS separate. I don't see how this is practice or plausible in a real deployment.
Also if it's worth anything backwards compatibility is a trap. Seems good now as causes a little less pain but after people have migrated just causes greater confusion and pain. Clean cut.