Bug 1508506
Summary: | [Ceph-ansible]: Stopping of NFS-server service required prior to installation of RGW-NFS | ||
---|---|---|---|
Product: | [Red Hat Storage] Red Hat Ceph Storage | Reporter: | Vidushi Mishra <vimishra> |
Component: | Ceph-Ansible | Assignee: | Ali Maredia <amaredia> |
Status: | CLOSED ERRATA | QA Contact: | Ameena Suhani S H <amsyedha> |
Severity: | high | Docs Contact: | Bara Ancincova <bancinco> |
Priority: | unspecified | ||
Version: | 3.0 | CC: | adeza, amaredia, amsyedha, aschoen, bancinco, ceph-eng-bugs, gabrioux, gmeno, hgurav, hnallurv, nthomas, pasik, sangadi, shan, tserlin, vashastr, vimishra |
Target Milestone: | z1 | ||
Target Release: | 3.3 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | RHEL: ceph-ansible-3.2.30-1.el7cp Ubuntu: ceph-ansible_3.2.30-2redhat1 | Doc Type: | Bug Fix |
Doc Text: |
.The `nfs-server` service is stopped and disabled automatically on the NFS Ganesha node
When the `nfs-server` service was running on the NFS Ganesha node, an attempt to start the NFS Ganesha instance after its installation failed. With this update, the `nfs-server` service is automatically stopped and disabled on the NFS Ganesha node before installing NFS Ganesha. As a result, the NFS Ganesha instance starts as expected after its installation.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2019-10-22 13:29:00 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: | |||
Bug Blocks: | 1494421 |
Description
Vidushi Mishra
2017-11-01 15:02:08 UTC
Bara, The exact name of the service is "nfs-server". In your description on this bug, everywhere you say "nfs-service" should be "nfs-server". -Ali Why was nfs-server running in the first place? Looks like a system misconfiguration to me. I get that this might be a system misconfiguration, but why wouldn't ceph-ansible be able to stop the service if it is running in order to continue the installation? Ok, so this sounds more like a request. I didn't get that this was on purpose. I guess we can if the service runs and stop it/disable it. However, I'm just really hesitant changing the system configuration, if kNFS is running it might be for a good reason. The best thing we should do IMHO is to check if the service runs, fail the playbook and ask to stop it before pursuing the installation. Is that acceptable to everyone? Thanks (In reply to leseb from comment #10) > Ok, so this sounds more like a request. > I didn't get that this was on purpose. > I guess we can if the service runs and stop it/disable it. > > However, I'm just really hesitant changing the system configuration, if kNFS > is running it might be for a good reason. > > The best thing we should do IMHO is to check if the service runs, fail the > playbook and ask to stop it before pursuing the installation. > > Is that acceptable to everyone? > Thanks Hi leseb, When we do the manual way of installing nfs-ganesha, it is mandatory to stop and disable kNFS before installing nfs-ganesha-rgw. NFS-Ganesha will not start if another NFS instance is running. As per the doc: " If the nfs-service service is running, stop and disable it: # systemctl stop nfs-server.service # systemctl disable nfs-server.service " As we are automating nfs-ganesha-rgw installation in 3.0, it will be better to stop and disable nfs-server.service via ceph-ansible. Thanks, Vidushi Here is a PR that stops the service before the nfs-ganesha service can be started: https://github.com/ceph/ceph-ansible/pull/2488 The above PR has been merged. Ceph-ansible now stops nfs-server via systemd if before it start nfs-ganesha. Verified using ceph-ansible-3.2.29-1.el7cp.noarch. Moving to VERIFIED state. 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://access.redhat.com/errata/RHBA-2019:3173 |