7662cde704849b424ad3497b10f5fef35ae0a947
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
Alistair Coles
|
d555755423 |
proxy_logging config: unit tests and doc pointers
Add unit tests to verify the precedence of access_log_ and log_ prefixes to options. Add pointers from proxy_logging sections in other sample config files to the proxy-server.conf-sample file. Change-Id: Id18176d3790fd187e304f0e33e3f74a94dc5305c |
||
|
Matthew Oliver
|
e5105ffa09 |
internal_client: Remove allow_modify_pipeline option
The internal client is suppose to be internal to the cluster, and as such we rely on it to not remove any headers we decide to send. However if the allow_modify_pipeline option is set the gatekeeper middleware is added to the internal client's proxy pipeline. So firstly, this patch removes the allow_modify_pipeline option from the internal client constructor. And when calling loadapp allow_modify_pipeline is always passed with a False. Further, an op could directly put the gatekeeper middleware into the internal client config. The internal client constructor will now check the pipeline and raise a ValueError if one has been placed in the pipeline. To do this, there is now a check_gatekeeper_loaded staticmethod that will walk the pipeline which called from the InternalClient.__init__ method. Enabling this walking through the pipeline, we are now stashing the wsgi pipeline in each filter so that we don't have to rely on 'app' naming conventions to iterate the pipeline. Co-Authored-By: Alistair Coles <alistairncoles@gmail.com> Change-Id: Idcca7ac0796935c8883de9084d612d64159d9f92 |
||
|
Alistair Coles
|
035d91dce5 |
Modify log_name in internal clients' pipeline configs
Modify the 'log_name' option in the InternalClient wsgi config for the following services: container-sharder, container-reconciler, container-deleter, container-sync and object-expirer. Previously the 'log_name' value for all internal client instances sharing a single internal-client.conf file took the value configured in the conf file, or would default to 'swift'. This resulted in no distinction between logs from each internal client, and no association with the service using a particular internal client. With this change the 'log_name' value will typically be <log_route>-ic where <log_route> is the service's conf file section name. For example, 'container-sharder-ic'. Note: any 'log_name' value configured in an internal client conf file will now be ignored for these services unless the option key is preceded by 'set'. Note: by default, the logger's StatdsClient uses the log_name as its tail_prefix when composing metrics' names. However, the proxy-logging middleware overrides the tail_prefix with the hard-coded value 'proxy-server'. This change to log_name therefore does not change the statsd metric names emitted by the internal client's proxy-logging. This patch does not change the logging of the services themselves, just their internal clients. Change-Id: I844381fb9e1f3462043d27eb93e3fa188b206d05 Related-Change: Ida39ec7eb02a93cf4b2aa68fc07b7f0ae27b5439 |
||
|
Clay Gerrard
|
90134ee968 |
add symlink to container sync default and sample config
Change-Id: I83e51daa994b9527eccbb8a88952c630aacd39c3 |
||
|
Alistair Coles
|
c662e5fc8e |
Add account_autocreate=true to internal-client.conf-sample
Closes-Bug: #1698426 Change-Id: I8a29a685bb12e60f4da4a0dc8270b408241ec415 |
||
|
gh159m
|
b5311f63db |
Removed default value for log_statsd_host
Multiple files and documents showed that log_statsd_host had a default value, usually localhost. This was incorrect, instead setting a value for log_statsd_host enables statsd logging. Removed any reference of log_statsd_host having a default value. Also changed descriptions to show setting a value enables logging. Change-Id: I3ca5c0e8b8e4981de3aa6db0c476072b5a59723d Closes-Bug: #1542227 |
||
|
Yuan Zhou
|
61a9d35fd5 |
Update container sync to use internal client
This patch changes container sync to use Internal Client instead of Direct Client. In the current design, container sync uses direct_get_object to get the newest source object(which talks to storage node directly). This works fine for replication storage policies however in erasure coding policies, direct_get_object would only return part of the object(it's encoded as several pieces). Using Internal Client can get the original object in EC case. Note that for the container sync put/delete part, it's working in EC since it's using Simple Client. Signed-off-by: Yuan Zhou <yuan.zhou@intel.com> DocImpact Change-Id: I91952bc9337f354ce6024bf8392046a1ecf6ecc9 |