Share cleanup job #337
Share cleanup job #337
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fmount The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
holding for now to review and discuss more about this. |
fmount
force-pushed
the
share_cleanup
branch
from
25f42a8 to
768f079
Compare
|
/test functional |
|
Looks good from a manila point of view and the removal makes sense! Thank you for working on this. @gouthampacha might want to take a look and share his thoughts too :) |
When a share is deleted from the top-level CR, its reference is not deleted, and manila still sees it as Down/not available. For this reason, every time a scale down operation is executed, we need to run a job that is supposed to run a service cleanup, removing everything set as down. Jira: https://issues.redhat.com/browse/OSPRH-6526 Signed-off-by: Francesco Pantano <[email protected]>
When a backend config is removed, the "service" database entry in manila needs to be adjusted to account for the removal. This patch introduces a Job that runs a manila-manage command every time a share is scaled down. The main job definition is now more flexible and we can pass a TTL in case we want to customize the time the job is kept. Signed-off-by: Francesco Pantano <[email protected]>
| @@ -48,6 +48,8 @@ const ( | |||
| ManilaPublicPort int32 = 8786 | |||
| // ManilaInternalPort - | |||
| ManilaInternalPort int32 = 8786 | |||
| // ServiceCleanupDelay - | |||
| ManilaServiceCleanupDelay int32 = 120 | |||
There was a problem hiding this comment.
@gouthampacha we delay according to this parameter.
| @@ -62,12 +70,13 @@ func DbSyncJob(instance *manilav1.Manila, labels map[string]string, annotations | |||
| }, | |||
| } | |||
|
|
|||
| args := []string{"-c", DBSyncCommand} | |||
| delayCommand := fmt.Sprintf("sleep %d", delay) | |||
| args := []string{"-c", fmt.Sprintf("%s && %s", delayCommand, jobCommand)} | |||
There was a problem hiding this comment.
@gouthampacha the resulting command is the concatenation between the delay and the jobCommand.
|
@gouthampacha @silvacarloss I made a few more local tests related to the fact we need to delay the job execution and here a summary. With the current behavior I think we're good to go. WRT documentation, I think we need to mention that we might need to restart the scheduler. @gouthampacha do we have any upstream bug or Jira to fix the scheduler? |
|
/test functional |
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/a6dbd5c6a6e94ba69592d7a48f9c342e ❌ openstack-k8s-operators-content-provider FAILURE in 8m 59s |
If the share cleanup job is executed right after the share deletion, it might be possible that the other manila components have not yet been notified about the event. The result is that the job has no effect. This patch introduces a parameter for the ManilaJob that is supposed to delay the command. A constant has been defined to properly indentify the delay time associated with the service cleanup. Signed-off-by: Francesco Pantano <[email protected]>
|
/test functional |
Agreed; as a known issue: https://bugs.launchpad.net/manila/+bug/1915094 |
|
/lgtm Thank you @fmount |
openshift-merge-bot
bot
merged commit e746e34
into
openstack-k8s-operators:main
When a backend config is removed, the "service" database entry in manila needs to be adjusted to account for the removal. This patch introduces a Job that runs a manila-manage command every time a share is scaled down. The main job definition is now more flexible and we can pass a
TTLin case we want to customize the time the job is kept.Jira: https://issues.redhat.com/browse/OSPRH-6526