Some output on the setup (relevant changed parts):
...
Setting up configuration management
Select the configuration management system. Make a selection please:
1: Arakoon
2: Etcd
Select Nr: [1]:
Use an external cluster? (y/[n]):
Setting up configuration Arakoon
...
Select the port to be used for the ASDs [8600]:
Select the configuration management system. Make a selection please:
1: Arakoon
2: Etcd
Select Nr: [1]:
[!!!] Please place a copy of the Arakoon's client configuration file at: /opt/asd-manager/config/arakoon_cacc.ini
[!!!] Press enter to continue
- Starting watcher service
The lines starting with "[!!!] " are optional and only printed in case the configuration file wasn't found at that point.
Changes on unattended setup:
Key external_etcd is gone
Key config_mgmt_type is added, values: "arakoon" or "etcd"
Key external_config added, values: True (in case of arakoon) or "config=http://ip:port" (in case of Etcd)
In case an external arakoon is used, the setup expects the cluster's config file to be available in "/opt/OpenvStorage/config/arakoon_cacc.ini", asd-manager setup expects it to be available in "/opt/asd-manager/config/arakoon_cacc.ini".
Other interesting changes:
There's a new config file /opt/OpenvStorage/config/framework.json containing the json {"configuration_store": "arakoon|etcd"} that must be available on all ovs nodes. In case of Arakoon there's the above arakoon_cacc.ini file available on all ovs and storagenodes. It might be provided by external means (unattended setup) during setup, but is afterwards maintained by the system. Whoever is responsible for managing this cluster should make sure that the key "__ovs_config" contains a raw dump of it's config file. The "ovs-watcher-config" (on ovs nodes) or "asd-watcher" (on storage nodes) (referred to as 1st-layer watchers) will monitor availability of this arakoon (referred to as 1st-layer arakoon). After ovs-watcher-config boots, it will start all other arakoons (ovsdb, voldrv, abm, nsm, referred to as 2nd-layer arakoons), which will cause the ovs-watcher-framework and ovs-watcher-voldrv (referred to as 2nd-layer watchers) to start and start up the rest of the framework/voldrv/proxy/... The "asd-watcher" will when started trigger a start of the asd-manager and the asds. If "asd-watcher" detects a change in the config arakoon's config ("__ovs_config"), it will update it's local arakoon_cacc.ini file and restart the asd-manager automatically. "ovs-watcher-config" will do the same for the ovs-nodes but will not restart the framework.
Some output on the setup (relevant changed parts):
... Setting up configuration management Select the configuration management system. Make a selection please: 1: Arakoon 2: Etcd Select Nr: [1]: Use an external cluster? (y/[n]): Setting up configuration Arakoon ... Select the port to be used for the ASDs [8600]: Select the configuration management system. Make a selection please: 1: Arakoon 2: Etcd Select Nr: [1]: [!!!] Please place a copy of the Arakoon's client configuration file at: /opt/asd-manager/config/arakoon_cacc.ini [!!!] Press enter to continue
- Starting watcher service
The lines starting with "[!!!] " are optional and only printed in case the configuration file wasn't found at that point.
Changes on unattended setup:
Other interesting changes:
There's a new config file /opt/OpenvStorage/config/framework.json containing the json {"configuration_store": "arakoon|etcd"} that must be available on all ovs nodes. In case of Arakoon there's the above arakoon_cacc.ini file available on all ovs and storagenodes. It might be provided by external means (unattended setup) during setup, but is afterwards maintained by the system. Whoever is responsible for managing this cluster should make sure that the key "__ovs_config" contains a raw dump of it's config file. The "ovs-watcher-config" (on ovs nodes) or "asd-watcher" (on storage nodes) (referred to as 1st-layer watchers) will monitor availability of this arakoon (referred to as 1st-layer arakoon). After ovs-watcher-config boots, it will start all other arakoons (ovsdb, voldrv, abm, nsm, referred to as 2nd-layer arakoons), which will cause the ovs-watcher-framework and ovs-watcher-voldrv (referred to as 2nd-layer watchers) to start and start up the rest of the framework/voldrv/proxy/... The "asd-watcher" will when started trigger a start of the asd-manager and the asds. If "asd-watcher" detects a change in the config arakoon's config ("__ovs_config"), it will update it's local arakoon_cacc.ini file and restart the asd-manager automatically. "ovs-watcher-config" will do the same for the ovs-nodes but will not restart the framework.