Bug 1380482
Summary: | The CephFS Native Manila Driver will Flood the Share Log with Errors when it Cannot Connect to Backing CephFS Cluster | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Dustin Schoenbrun <dschoenb> | ||||
Component: | openstack-manila | Assignee: | Jan Provaznik <jprovazn> | ||||
Status: | CLOSED ERRATA | QA Contact: | Dustin Schoenbrun <dschoenb> | ||||
Severity: | unspecified | Docs Contact: | Don Domingo <ddomingo> | ||||
Priority: | unspecified | ||||||
Version: | 10.0 (Newton) | CC: | dschoenb, jjoyce, jprovazn, jschluet, mlopes, pgrist, tbarron | ||||
Target Milestone: | rc | Keywords: | Triaged | ||||
Target Release: | 10.0 (Newton) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | openstack-manila-3.0.0-5.el7ost | Doc Type: | Bug Fix | ||||
Doc Text: |
Prior to this update, the Manila Ceph FS driver did not check if it could connect to the Ceph server.
Consequently, if the connection to the Ceph server did not work, `manila-share` service kept crashing or respawning without any timeout.
With this update, there is now a check to confirm that the Ceph connection works when initializing the Manila Ceph FS driver. As a result, the Ceph driver checks the Ceph connection on driver init, and if it fails the driver is not initialized and no further steps are performed.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-12-14 16:06:11 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: | |||||||
Attachments: |
|
Description
Dustin Schoenbrun
2016-09-29 17:49:59 UTC
We should investigate whether this is a CephFS driver-specific issue or whether any manila backend that fails to connect to external storage will do the same thing. And if the latter, is this a problem also in cinder? Targeting 10z, but if this is very problematic then consider bringing it back. upstream bug: https://bugs.launchpad.net/manila/+bug/1640169 Created attachment 1222498 [details]
head of /var/log/manila/share.log after native cephfs driver deployed w/o actual cephfs backend
I used OSPd to deploy the native cephfs backend for manila via '-e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml' using the latest rhos10 puddle, core_puddle=2016-11-19.4. Results are in https://bugzilla.redhat.com/attachment.cgi?id=1222498, where one can readily see that the manila share log shows that the manila share service correctly determines that it cannot interact with the backend. Instead of retrying in a quick loop as reported in this BZ and in https://bugs.launchpad.net/manila/+bug/1640169 the share service instead declares: 2016-11-21 22:39:54.682 113290 ERROR oslo_service.periodic_task DriverNotInitialized: Share driver 'CephFSNativeDriver' not initialized. This message is seen again on periodic task updates that require interaction with the driver: 2016-11-21 22:40:54.682 113290 ERROR oslo_service.periodic_task DriverNotInitialized: Share driver 'CephFSNativeDriver' not initialized. In other words, the current log shows behavior consistent with other backends, and not the tight infinite loop of retries to connect to the CephFS cluster as reported in this bug. Thanks for having a look at this, Tom! Looks good to me. Marking the bug as VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2948.html |