311045f01f
virtual-chassis test uses multiple vs instances to simulate a modular switch and a redis-chassis service is required to run on the vs instance that represents a supervisor card. This change allows vs docker start redis-chassis service according to external config file. **- Why I did it** To support virtual-chassis setup, so that we can test distributed forwarding feature in virtual sonic environment, see `Distributed forwarding in a VOQ architecture HLD` pull request at https://github.com/Azure/SONiC/pull/622 **- How I did it** The sonic-vs start.sh is enhanced to start new redis_chassis service if external chassis config file found. The config file doesn't exist in current vs environment, start.sh will behave like before. **- How to verify it** The swss/test still pass. The chassis_db service is verified in virtual-chassis topology and tests which are in following PRs. Signed-off-by: Honggang Xu <hxu@arista.com> (cherry picked from commit c1d45cf81ce3238be2dcbccae98c0780944981ce) Co-authored-by: Honggang Xu <hxu@arista.com>
14 lines
413 B
Python
14 lines
413 B
Python
#!/usr/bin/env python
|
|
|
|
import swsssdk
|
|
import json
|
|
chassisdb = swsssdk.SonicV2Connector(host='10.0.0.200', port='6380')
|
|
chassisdb.connect(chassisdb.CHASSIS_DB)
|
|
fname='/usr/share/sonic/virtual_chassis/chassis_db.json'
|
|
with open(fname) as f:
|
|
js = json.load(f)
|
|
client=chassisdb.get_redis_client(chassisdb.CHASSIS_DB)
|
|
for h, table in js.items():
|
|
for k, v in table.items():
|
|
client.hset(h, k, v)
|