| 2022-09-26 11:26:36 |
kiran pawar |
description |
Issue
=====
Manila services are created(in DB) in the start() method. DB consider unique service, based on service-name and host-name combination. However when services are stopped or restarted, the DB entries are not deleted, they are destroyed only in kill() method.
scenario
========
1. In big cluster where multiple instances of manila-scheduler are launched, unique host-name (we use node-name of k8s) and service-name the entries are created in DB.
2. However when deployed again and launched on new hosts, the old entries of manila-scheduler remains as it is.
Solution
========
To overcome this situation, we should remove the DB entry each time service is stopped or killed and create new entry again in start() method.
Exception
========
1. This issue does not reproduce on devstack where single host and single instance of manila-scheduler is used.
2. This issue does not observed for manila-share services since hostname is host@backend which is unique across deployments. |
Issue
=====
Manila services are created(in DB) in the start() method. DB consider unique service, based on service-name and host-name combination. However when services are stopped or restarted, the DB entries are not deleted, they are destroyed only in kill() method.
scenario
========
1. In big cluster where multiple instances of manila-scheduler are launched, unique host-name (we use node-name of k8s) and service-name the entries are created in DB.
2. However when deployed again and launched on new hosts, the old entries of manila-scheduler remains as it is.
Solution
========
To overcome this situation, we should remove the DB entry each time service is stopped or killed and create new entry again in start() method.
Exception
========
1. This issue does not reproduce on devstack where single host and single instance of manila-scheduler is used.
2. This issue is not observed for manila-share services since hostname is host@backend which is unique across deployments. |
|
