Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add configurable API Timeouts #396

Merged
merged 1 commit into from
Jun 7, 2024

Conversation

Akrog
Copy link
Contributor

@Akrog Akrog commented Jun 6, 2024

Multiple limitations exist with existing code:

  • Human operator cannot configure Apache Timeout, so it's fixed at the defaults of 60 seconds.

    This can be problematic for cinder backends that under load can take longer on the export and mapping.

  • Default HAProxy timeout is 30 seconds, which is different than the default in OSP17 (60 seconds)

  • Human operators would need to sync values between 3 places: HAProxy, Apache, oslo.messaging sync RPC (call).

This patch adds an apiTimeout field to the CinderSpecBase to allow human operators to simultaneously configure the timeouts for HAProxy, Apache, and the rpc_response_timeout.

The apiTimeout defaults to 60 seconds, to mimic the behavior present in OSP17.

Having different timeouts for HAProxy, Apache, and rpc_response_timeout is possible setting the HAProxy timeout in the apiOverride, the Apache timeout with apiTimeout, and setting rpc_response_timeout in the top level Cinder customServiceConfig.

To be able to change the HAProxy value based on the apiTimeout with any update (and not just the first time) the code adds a custom annotation "api.cinder.openstack.org/timeout" with the value that was initially set, this way flags it as being set by the cinder-operator.

Jira: https://issues.redhat.com/browse/OSPRH-7393

Multiple limitations exist with existing code:

- Human operator cannot configure Apache Timeout, so it's fixed at the
  defaults of 60 seconds.

  This can be problematic for cinder backends that under load can take
  longer on the export and mapping.

- Default HAProxy timeout is 30 seconds, which is different than the
  default in OSP17 (60 seconds)

- Human operators would need to sync values between 3 places: HAProxy,
  Apache, oslo.messaging sync RPC (call).

This patch adds an `apiTimeout` field to the `CinderSpecBase` to allow
human operators to simultaneously configure the timeouts for HAProxy,
Apache, and the `rpc_response_timeout`.

The `apiTimeout` defaults to 60 seconds, to mimic the behavior present
in OSP17.

Having different timeouts for HAProxy, Apache, and
`rpc_response_timeout` is possible setting the HAProxy timeout in the
`apiOverride`, the Apache timeout with `apiTimeout`, and setting
`rpc_response_timeout` in the top level Cinder `customServiceConfig`.

To be able to change the HAProxy value based on the `apiTimeout` with
any update (and not just the first time) the code adds a custom
annotation "api.cinder.openstack.org/timeout" with the value that was
initially set, this way flags it as being set by the cinder-operator.

Jira: https://issues.redhat.com/browse/OSPRH-7393
@openshift-ci openshift-ci bot requested review from ASBishop and dprince June 6, 2024 14:12
@openshift-ci openshift-ci bot added the approved label Jun 6, 2024
Akrog added a commit to Akrog/openstack-operator that referenced this pull request Jun 6, 2024
softwarefactory-project-zuul bot added a commit to openstack-k8s-operators/architecture that referenced this pull request Jun 6, 2024
Set HAProxy timeout to 60 seconds for storage

This patch sets the HAProxy timeout to 60 seconds for storage services (Cinder, Glance, and Manila).
This way it's in sync with the Apache default timeouts and matches what we have in OSP17.
This will be fixed in the operators themselves to have these same defaults, and this patch is compatible with that change.
When the operators code is merged and is run by the CI jobs the defaults in the operators will be ignored in favor of the defaults defined in this patch, so we'll want to revert this patch then.
These are the PRs that once their code is run on the CI we can revert this PR:

openstack-k8s-operators/cinder-operator#396
openstack-k8s-operators/glance-operator#550
openstack-k8s-operators/manila-operator#282
openstack-k8s-operators/openstack-operator#830

Jira: https://issues.redhat.com/browse/OSPRH-7393
Jira: https://issues.redhat.com/browse/OSPRH-7415

Reviewed-by: Andrew Bays <andrew.bays@gmail.com>
@fmount
Copy link
Contributor

fmount commented Jun 7, 2024

looks good but I'll let @ASBishop approve

Copy link
Contributor

@fmount fmount left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Copy link
Contributor

openshift-ci bot commented Jun 7, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Akrog, 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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-bot openshift-merge-bot bot merged commit 9a88752 into openstack-k8s-operators:main Jun 7, 2024
7 checks passed
Akrog added a commit to Akrog/openstack-operator that referenced this pull request Jun 7, 2024
Akrog added a commit to Akrog/openstack-operator that referenced this pull request Jun 7, 2024
@Akrog Akrog deleted the apiTimeout branch June 7, 2024 13:16
Akrog added a commit to Akrog/openstack-operator that referenced this pull request Jun 7, 2024
abays pushed a commit to Akrog/openstack-operator that referenced this pull request Jun 7, 2024
abays pushed a commit to Akrog/openstack-operator that referenced this pull request Jun 10, 2024
Akrog added a commit to Akrog/openstack-operator that referenced this pull request Jun 10, 2024
abays pushed a commit to Akrog/openstack-operator that referenced this pull request Jun 10, 2024
abays pushed a commit to Akrog/openstack-operator that referenced this pull request Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants