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

.maintenance.flag and .maintenance.ip files are stored in, and queried from S3 bucket, when S3 storage is enabled. #39047

Open
5 tasks
gwharton opened this issue Aug 14, 2024 · 9 comments
Assignees
Labels
feature request Progress: dev in progress Reported on 2.4.7-p1 Indicates original Magento version for the Issue report. Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it

Comments

@gwharton
Copy link
Contributor

Preconditions and environment

2.4.7-p1
S3 Storage Enabled

Steps to reproduce

Deploy 2.4.7-p1
Enable S3 Storage
Enable Maintenance Mode

Expected result

I wouldn't expect the mechanism to determine whether Magento is in maintenance mode or not to require a remote call to the S3 bucket.

Actual result

Every time my server is hit at the frontend, it fires off an API call to the S3 bucket to check for .maintenance.flag

Additional information

Not a bug as such, but feels like something that crept in without noticing when remote storage was envisaged.

I'm sure there are use cases to have a central .maintenance.flag shared across all instances

Release note

No response

Triage and priority

  • Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Copy link

m2-assistant bot commented Aug 14, 2024

Hi @gwharton. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:


Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

@engcom-Bravo engcom-Bravo added the Reported on 2.4.7-p1 Indicates original Magento version for the Issue report. label Aug 16, 2024
@makkoff
Copy link

makkoff commented Aug 16, 2024

@magento give me 2.4-develop instance

Copy link

Hi @makkoff. Thank you for your request. I'm working on Magento instance for you.

Copy link

@engcom-Hotel engcom-Hotel moved this to Ready for Confirmation in Issue Confirmation and Triage Board Aug 19, 2024
@engcom-Hotel engcom-Hotel added the Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it label Sep 25, 2024
@engcom-Hotel engcom-Hotel self-assigned this Sep 25, 2024
Copy link

m2-assistant bot commented Sep 25, 2024

Hi @engcom-Hotel. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

  • 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  • 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
  • 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
  • 4. Verify that the issue is reproducible on 2.4-develop branch
    Details- If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
  • 5. Add label Issue: Confirmed once verification is complete.
  • 6. Make sure that automatic system confirms that report has been added to the backlog.

@engcom-Hotel
Copy link
Contributor

Hello @gwharton,

Thanks for the report and collaboration!

It seems to us an expected behavior to check whether the Magento is in maintenance mode or not. And because we enabled the S3, all assets are kept in the S3 bucket only that's why an API has been triggering to check the mode of Magento.

Please let us know if we have missed anything here.

Thanks

@engcom-Hotel engcom-Hotel moved this from Ready for Confirmation to Needs Update in Issue Confirmation and Triage Board Sep 25, 2024
@engcom-Hotel engcom-Hotel added Issue: needs update Additional information is require, waiting for response and removed Issue: ready for confirmation labels Sep 25, 2024
@gwharton
Copy link
Contributor Author

I agree it is the exected behaviour given the current implementation.

I was however querying whether it is the right behaviour.

API calls to S3 are chargable per call.

Several calls are made to S3 to check if maintenance mode is enabled for every instantiation of the Magento App which both increases costs, and also increases latency to the end user.

@engcom-Hotel
Copy link
Contributor

Hello @gwharton,

I agree with your point that S3 API calls have been chargeable. Keeping this in mind, I am marking this issue as a feature request for further processing.

Thanks

@gwharton
Copy link
Contributor Author

gwharton commented Sep 26, 2024

Yeah, not a bug as such, just could do with improvement.

The functionality is well abstracted, so would seem possible to provide a configurable maintenance flag system with options to use

  1. Automatic Filesystem (local or remote if enabled, current implementation)
  2. Flag table in database (supports multi node, is the DB configured this early in the bootstrap?)
  3. Local Filesystem (single node)
  4. Remote Filesystem (if remote enabled, supports multi node)

Perhaps configurable through di.xml with the default being the current implementation. Thus giving people the option to keep the maintenance files local if they only run single node for increased speed, or even keep the flag in the database, should that be possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Progress: dev in progress Reported on 2.4.7-p1 Indicates original Magento version for the Issue report. Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it
Projects
Status: Ready for Grooming
Development

No branches or pull requests

4 participants