Bug 1336237
| Summary: | [Doc] Hypervisor summary shows incorrect total storage (Ceph) | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Don Domingo <ddomingo> | |
| Component: | documentation | Assignee: | Don Domingo <ddomingo> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | RHOS Documentation Team <rhos-docs> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.0 (Kilo) | CC: | bengland, berrange, brault, dasmith, ddomingo, derli, eglynn, kchamart, kimi.zhang, mschuppe, ndipanov, nlevine, nlevinki, panbalag, rdopiera, rsussman, sbauza, sferdjao, sgordon, sknauss, srevivo, vromanso, yeylon | |
| Target Milestone: | --- | Keywords: | Documentation, Triaged, ZStream | |
| Target Release: | 9.0 (Mitaka) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Known Issue | ||
| Doc Text: |
When using Red Hat Ceph as a back end for ephemeral storage, the Compute service does not calculate the amount of available storage correctly. Specifically, Compute simply adds up the amount of available storage without factoring in replication. This results in grossly overstated available storage, which in turn could cause unexpected storage oversubscription.
To determine the correct ephemeral storage capacity, query the Ceph service directly instead.
|
Story Points: | --- | |
| Clone Of: | 1332165 | |||
| : | 1368279 (view as bug list) | Environment: | ||
| Last Closed: | 2016-08-19 00:47:21 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: | ||||
| Bug Depends On: | 1236473, 1311508, 1332165 | |||
| Bug Blocks: | 1368279, 1430245 | |||
|
Comment 1
Don Domingo
2016-05-16 00:59:54 UTC
Closing this for OSP9 so we can have the warning added to the Release Notes. Cloning for OSP10 for the same reasons, and also so we can track it for OSP10. |