Bug 1382921
Summary: | swift-object-expirer packaged in wrong package | ||
---|---|---|---|
Product: | [Community] RDO | Reporter: | Otavio Salvador <otavio> |
Component: | openstack-swift | Assignee: | Tzach Shefi <tshefi> |
Status: | CLOSED WONTFIX | QA Contact: | nlevinki <nlevinki> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | Mitaka | CC: | cschwede, derekh, dmsimard, srevivo, thiago, zaitcev |
Target Milestone: | --- | ||
Target Release: | trunk | ||
Hardware: | All | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-06-09 09:36:38 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Otavio Salvador
2016-10-08 11:31:39 UTC
The object-expirer service is usually run on proxies. It uses the internal client to access storage nodes, so it is isomorphic with the proxy. It is not advisable to run it on object storage nodes. Therefore, it is co-packaged with the proxy. If object-exporer were to packaged with object-storage service, then it would be impossible to run on proxies that do not have object-storage RPM installed, and that is not acceptable. The bug appears to be in whatever orchestration is yielding the above result. If the orchestration is too hard to fix, we could pull the binary into python-swift, I suppose. The place where it is usually used should not determine where it belongs. As the utility name says, it is related to the objects and not to the proxy. In fact for a even more flexible usage, maybe it could have a own package? people then can decide if install it on proxy or not. I believe this should be closed as 'invalid' or 'won't fix'. I can understand how the name may seem to imply that this is a service that it is typically run like the other background object services, but this is not necessarily the case. What I have found from talking to various operators involved in the Swift community is that there's not really one right approach to running the object expirer. In my very unscientific survey of asking people on IRC, I realized that it was pretty evenly split how ops are running the expirer. About half run on the proxies nodes and the other half run on the storage nodes. There are also those, that actually run the expirer on a separate node (together with other auxiliary services like statsd server). Sure, we could break the proxy rpm down into 3 rpms, one for expirer, one for reconciler (which has the exactly same issue) and one for the proxy itself, but I think this is a minor enough problem that does not warrant the overhead of two more rpms to track for Swift. @Otavio, I think you took the correct approach of creating a kolla image for the expirer, that way, operators can choose to run that container wherever they see fit. Closing based on the comments from Pete & Thiago. |