Commit Graph

9 Commits

Author SHA1 Message Date
SuvarnaMeenakshi
0099305475 Multi-ASIC implementation (#3888)
Changes made to support multi-asic platform. Added multi-instance support for swss, syncd, database, bgp, teamd and lldp.
2020-04-15 13:08:34 -07:00
Abhishek Dosi
249265ad99 Revert "Multi-ASIC implementation (#3888)"
This reverts commit 2e87a16941.
2020-04-03 14:34:38 -07:00
SuvarnaMeenakshi
2e87a16941 Multi-ASIC implementation (#3888)
Changes made to support multi-asic platform. Added multi-instance support for swss, syncd, database, bgp, teamd and lldp.
2020-04-01 23:21:49 -07:00
SuvarnaMeenakshi
abe7ef7e2e [baseimage]: support building multi-asic component (#3856)
- move single instance services into their own folder
- generate Systemd templates for any multi-instance service files in slave.mk
- detect single or multi-instance platform in systemd-sonic-generator based on asic.conf platform specific file.
- update container hostname after creation instead of during creation (docker_image_ctl)
- run Docker containers in a network namespace if specified
- add a service to create a simulated multi-ASIC topology on the virtual switch platform

Signed-off-by: Lawrence Lee <t-lale@microsoft.com>
Signed-off-by: Suvarna Meenakshi <Suvarna.Meenaksh@microsoft.com>
2020-02-03 15:32:21 -08:00
Dong Zhang
768beb79e1 create multiple Redis DB instances based on CONFIG at /etc/sonic/database_config.json (#2182)
this is the first step to moving different databases tables into different database instances

in this PR, only handle multiple database instances creation based on user configuration at /etc/sonic/database_config.json

we keep current method to create single database instance if no extra/new DATABASE configuration exist in database_config.json file.

if user try to configure more db instances at database_config.json , we create those new db instances along with the original db instance existing today.

The configuration is as below, later we can add more db related information if needed:
{
...
"DATABASE": {
"redis-db-01" : {
"port" : "6380",
"database": ["APPL_DB", "STATE_DB"]
},
"redis-db-02" : {
"port" : "6381",
"database":["ASIC_DB"]
},
}
...
}

The detail description is at design doc at Azure/SONiC#271

The main idea is : when database.sh started, we check the configuration and generate corresponding scripts.

rc.local service handle old_config copy when loading new images, there is no dependency between rc.local and database service today, for safety and make sure the copy operation are done before database try to read it, we make database service run after rc.local

Then database docker started, we check the configuration and generate corresponding scripts/.conf in database docker as well.

based on those conf, we create databases instances as required.

at last, we ping_pong check database are up and continue


Signed-off-by: Dong Zhang d.zhang@alibaba-inc.com
2019-08-28 11:15:10 -07:00
Joe LeVeque
2bb5400948 [services] Services which start containers now use 'docker wait' instead of 'docker attach' (#2661) 2019-03-08 10:59:41 -08:00
Qi Luo
c2ae736f2e [warmboot] Load database from redis-cli save (#2287)
* [warmboot] Load database from `redis-cli save`

Signed-off-by: Qi Luo <qiluo-msft@users.noreply.github.com>

* Add trivial statement to make bash function valid

Signed-off-by: Qi Luo <qiluo-msft@users.noreply.github.com>

* Update submodule sonic-utilities: Use 'redis-cli save' to dump database to file

Signed-off-by: Qi Luo <qiluo-msft@users.noreply.github.com>

* Move configdb-load.sh outside docker, and only run in cold

Signed-off-by: Qi Luo <qiluo-msft@users.noreply.github.com>

* Fix for more strict warm check

Signed-off-by: Qi Luo <qiluo-msft@users.noreply.github.com>
2018-11-22 15:13:35 -08:00
Taoyu Li
42ae02b665 [oneimage]: Fix race condition in systemd container services (#421)
When Type=simple, systemd will consider the service activated immediately
after specified in ExecStart process is started. If there is downstream
service depending on the state prepared in ExecStart, there will be race condition.

For example, issue #390. In this case, database.service calls database.sh, which
calls docker run or docker start -a to start database container. However, systemd
considers database.service successfully started at the time database.sh begins,
not after docker run finishes. As database.service is consider started, bgp.service
can be started. The redis database, which bgp service depends on, might or might not
have been started at this time point.

To fix this issue (and still keeping the functionality to monitor docker status with
systemd), we split the ExecStart process into an ExecStartPre part and an ExecStart
part. docker run is splitted into docker run -d then docker attach , while docker start
-a  is splitted into docker start and then docker attach. In this way, we make sure
the downstream services are blocked until container is successfully started.
2017-03-22 13:26:00 -07:00
Oleksandr Ivantsiv
34ea91349c one image implementation (#215)
* Single image

* Fix review comments

* Update syncd service. Add HW mgmt to Mellanox single image.

* Add single image template for Broadcom platform.

SKU should be provided during configure:
make configure PLATFORM=broadcom SKU=Force10-S6000

* Add single image template for Cavium platform.

SKU should be provided during configure:
make configure PLATFORM=cavium SKU=AS7512

* Add description to sonic_debian_extension.j2 file.
2017-01-29 11:33:33 -08:00