Bug 986869
| Summary: | PRESET: add nfs.target to preset file | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jóhann B. Guðmundsson <johannbg> | ||||
| Component: | systemd | Assignee: | systemd-maint | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | johannbg, lnykryn, mschmidt, msekleta, notting, plautrba, systemd-maint, vpavlin, zbyszek | ||||
| 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: | 2013-07-22 14:39:33 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
Jóhann B. Guðmundsson
2013-07-22 09:52:23 UTC
Created attachment 776844 [details]
add nfs.target to preset
Hm, so nfs.target, which requires rpcbind.service, would be always enabled. This doesn't seem to be a good solution. Maybe if the users are expecting 'systemctl enable nfs.service' to do the whole job, it would be better to add '[Install] Also=nfs.target' to nfs.service? (In reply to Zbigniew Jędrzejewski-Szmek from comment #2) > Hm, so nfs.target, which requires rpcbind.service, would be always enabled. > This doesn't seem to be a good solution. Maybe if the users are expecting > 'systemctl enable nfs.service' to do the whole job, it would be better to > add '[Install] Also=nfs.target' to nfs.service? That would be one way of solving it anyway closing this since it's best to leave it up to Steve to clean up his own mess and his "feelings" instead of us being wasting our time and effort trying to help him out. He can the re-propose this when he realizes that it's necessary and "feels" like it. Could someone explain to me what the semantical *meaning* of nfs.target is? If I (as a Fedora user) do systemctl enable nfs.target, what is it that I am really enabling? (To be clear, I would not consider a reply "Just look at the unit files' deps!" satisfactory. I really want to know what the *intent* is. How it is *supposed to* work from the user's point of view.) (In reply to Michal Schmidt from comment #4) > Could someone explain to me what the semantical *meaning* of nfs.target is? > If I (as a Fedora user) do systemctl enable nfs.target, what is it that I am > really enabling? > (To be clear, I would not consider a reply "Just look at the unit files' > deps!" satisfactory. I would not do that since you would have to look at two places what I submitted and what Steve then implemented I guess based on his feelings without looking into the units and dependency in them and their correlation to the nfs.target ( instead of actually implement the whole set of submitted units he decided to cherry pick some of them while leaving some of unsplitted ones as is ) > I really want to know what the *intent* is. How it is > *supposed to* work from the user's point of view.) That you enable activate that target only ( as the command suggest ) you then can proceed with enabling the rest of all the services within the target since they are dependent on various implementation/setup of nfs in infrastructure ( and the dependency in the services ) and easily disable nfs along with all the services by simply disabling the target itself. The target itself was always meant to be enabled when you install the nfs-utils package since it takes care of the shared dependency in all of the nfs units. |