Closed Bug 1361440 (bmo-cloud-migration) Opened 7 years ago Closed 6 years ago

BMO Cloud Ops Migration

Categories

(bugzilla.mozilla.org :: General, enhancement)

Production
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dylan, Assigned: dylan)

References

(Blocks 2 open bugs)

Details

I'd like to split the tasks that relate to *allowing* BMO to run in cloud services from the work of actually running it in cloud services. This nicely decouples work that I (or the B-Team Irregulars) can do from the work that needs work on the cloud-services side.

So this tracking bug is to keep track of those tasks, starting with the containerization bug 1361439
Depends on: 1386336
Depends on: 1402097
Depends on: 1403344
Depends on: 1403777
Depends on: 1404092
No longer depends on: 1404092
Depends on: 1406239, 1406235
Summary: Make BMO compatible with the operational requirements for hosting on cloud services → BMO Cloud Ops Migration
Depends on: 1430824
Depends on: bmo-cloud-daemons
Alias: bmo-cloud-migration
Blocks: 1431822
No longer blocks: 1431822
Depends on: 1431822
This isn't a bug per se, but please make sure the nginx in front of our webheads allows HTTP header fields to be at least 8k.
nginx defaults to 4k, and apache to 8k, and ... we hit that number under normal conditions.

The limit for *all* the headers together is larger than that number too, c.f. apache 2.2 docs.
Flags: needinfo?(bobm)
(In reply to Dylan Hardison [:dylan] (he/him) from comment #1)

> The limit for *all* the headers together is larger than that number too,
> c.f. apache 2.2 docs.

Sounds like we will need to tweak both the large_client_header_buffers and client_max_body_size settings.  What's the largest reasonable body size we should support from clients?  Default is 1MB.  Are you aware of any production stats we can use to tune these parameters?  

The documentation for those settings live here:
http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
Flags: needinfo?(bobm) → needinfo?(dylan)
Depends on: 1434675
(In reply to Bob Micheletto [:bobm] from comment #2)
> (In reply to Dylan Hardison [:dylan] (he/him) from comment #1)
 
> The documentation for those settings live here:
> http://nginx.org/en/docs/http/ngx_http_core_module.
> html#large_client_header_buffers
> http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

Looks like the default is 8k.  What should we use for a client_max_body_size?
Depends on: bmo-cloud-logs
Depends on: 1438022
Depends on: bmo-cloud-emails
Depends on: bmo-cloud-jobqueue
No longer depends on: 1403344
client body should be 10240 * 1024 bytes. That value is from data/params (or /editparams.cgi)
and is directly related to the mysql max packet size.

In other words, if nginx client body is smaller, Bugzilla maxattachmentsize and mysql max_packet_size should all agree.
Flags: needinfo?(dylan)
Depends on: 1442099
Depends on: 1445418
Depends on: 1447669
Blocks: 1448036
Depends on: 1449230
See Also: → bmo-cloud-issues
Depends on: 1449234
Depends on: bmo-cloud-issues
No longer depends on: 1449234
Depends on: 1451322
Follow up work depends on this bug, not the other way around.
No longer depends on: 1445418, bmo-cloud-issues
The migration completed on 2018/03/24.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.