| Summary: | engine setup requires restart of nfs services to work | ||
|---|---|---|---|
| Product: | [Community] ovirt-system-tests | Reporter: | Eyal Edri <eedri> |
| Component: | General | Assignee: | Yaniv Kaul <ykaul> |
| Status: | CLOSED NOTABUG | QA Contact: | Pavel Stehlik <pstehlik> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 2.0 | CC: | bugs, dcaroest, didi, eedri |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-04-12 13:34:48 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: | |
|
Description
Eyal Edri
2016-03-29 15:22:03 UTC
I removed it from the scripts and the runs did not fail on that yet (some even passed), so it might have been already solved (In reply to David Caro from comment #1) > I removed it from the scripts and the runs did not fail on that yet (some > even passed), so it might have been already solved Please let me know if it still happens. Might be related to bug 1302667? What OS? I do not follow closely ovirt-system-tests, and it's not clear from the description if the bug is about NFS storage configured by engine-setup or outside. If by engine-setup, the bug should be opened on it, not on ovirt-system-tests. el6 for the engine, el7 for the hosts (In reply to Eyal Edri from comment #0) > Description of problem: > When install ovirt-engine with ovirt-system-tests, add host fails if we > don't restart the following services: > > # make sure basic services are running > # without this the hosts fail to add > service rpcbind start > service nfslock start > chkconfig rpcbind on > chkconfig nfslock on Where? On engine? hosts? both? Where is the nfs server? The nfs server is on it's own vm, the services were started and enabled on the engine (In reply to David Caro from comment #6) > The nfs server is on it's own vm, the services were started and enabled on > the engine What I understand so far is: We have engine on machine A We have a host on machine B We have an nfs server on machine C The host B nfs-mount exports of machine C For some reason, at least in the past, we had to start these services on machine A, the engine, even though it's not playing an nfs server nor an nfs client. Right? I am probably missing something. Not much actually: We have el6 engine on vm A We have 2xel7 hosts on vms B and C We have el7 nfs on vm D We have el7 iscsi on vm E The hosts B and C nfs-mount the export of machine D. For some reason, at least in the past, we had to start these services on machine A, the engine, even though it's not playing as nfs server or nfs client. OK. Any change to find out when it was last broken and/or this was added as a fix?
And, BTW, since I am not familiar with this project, where is this quote taken from?
> # make sure basic services are running
> # without this the hosts fail to add
> service rpcbind start
> service nfslock start
> chkconfig rpcbind on
> chkconfig nfslock on
Can't find it in ovirt-system-tests git repo. I can find similar commands, but not the comment.
Re the actual issue, if indeed it deals with the engine machine, it probably refers to nfs services configured/required/started by engine-setup for serving a local nfs ISO domain. Indeed in the past we had similar issues, not sure about specific case. Generally speaking, if you encounter such issues, please open bugs against the relevant component instead of working around it in testing. And if you do workaround, perhaps add a comment "# needed to work around bz#NNNNNNN" :-)
For now, unless we know about a specific issue, I'd just remove this workaround and wait till it fails.
As I said on the first comment I made: """ I removed it from the scripts and the runs did not fail on that yet (some even passed), so it might have been already solved """ So that's we are doing I'm closing this bug as we don't see this problem anymore. |