ceph-mgr is difficult to put behind an nginx reverse proxy configuration
currently because of the HTTP return codes that it uses in different
situations.
We have 3 ceph-mgr servers (one on each of 3 monitors). Only 1 is ever
active. We do not expose the monitors outside of the cluster, so we cannot
point the browser directly at the manager IP address, instead we have an
nginx proxy server setup on a separate administrative node in front of the
cluster.
When a reverse proxy asks an inactive manager for the root URL (/), the
inactive mgr will return a 302 redirect code referencing the active mgr
node - which is good, we can handle that. However, when the reverse proxy
requests content from the inactive mgr, for example requesting something
like "/runtime.26209474bfa8dc87a77c.js", the inactive mgr returns a 404 Not
Found error instead of a 302 redirect. This makes it difficult
(impossible?) to get all of the content if an inactive ceph-mgr is selected
by the reverse proxy.
It would be nice if any request to an inactive ceph-mgr returned a 302 with
the correct location (and full URI path) to the client (the reverse proxy
in this case).
thanks,
Wyllys Ingersoll
Hi, developers :
i want's study the bitmap allocator, but a little hard to understand by
reading code, who has bitmap design document, thanks for your help!
Hi All,
Recently I added a support for bucket notifications, as part of the feature
the standard (s3) way for filtering notification was extended with new
fields that are not supported by AWS. This poses 2 issues:
- how to test it
- how users should use it
Crafting these messages "by hand" (e.g. by using curl) is not ideal for
both usecases.
However, according to this [1], there is an easy way to extend the standard
by changing a json file and then placing it under ~/.aws/models/s3/...
Or, placing it anywhere else, and then setting its path first in
the AWS_DATA_PATH search path (I tried the 1st options and it worked!).
I guess that this is not the only case where we want to extend/modify what
ASW/boto3 supports.
Would suggest that we add our own versions of the relevant files (e.g.[2])
into the ceph repo (not sure where?).
This could be used for:
- teuthology infra can take these files and use them, so that the clients
could test our extension natively with boto3
- we can add documentation around these files, so they are available to
users (maybe deliver them in the installation packages)
Of course, we will have to track changes to the original file, and merge
from time top time...
Yuval
[1] https://github.com/boto/botocore/blob/develop/botocore/loaders.py#L33
[2]
https://github.com/boto/botocore/blob/develop/botocore/data/s3/2006-03-01/s…
