Bug 1525957

Summary:	Don't start service by default
Product:	[Fedora] Fedora	Reporter:	Colin Walters <walters>
Component:	glusterfs	Assignee:	Kaleb KEITHLEY <kkeithle>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	high
Version:	rawhide	CC:	anoopcs, dustymabe, humble.devassy, jonathansteffan, jshubin, kkeithle, matthias, ndevos, ramkrsna, walters
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-01-11 12:41:05 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:

Description Colin Walters 2017-12-14 13:50:03 UTC

Currently the glusterfs %post through lots of convolutions ends up calling `systemctl start glusterfs`.  This is a violation of the guidelines; see:
https://fedoraproject.org/wiki/Packaging:Systemd


Why don't we....

    Start the service after installation?

Installations can be in changeroots, in an installer context, or in other situations where you don't want the services autostarted. 

Another reason for this is that almost always for nontrivial services admins want to configure the service *before* starting.

There's a whole "preset" model which is intended to handle services which start by default.

So let's change glusterfs to not start by default - and whatever "installers" people use for glusterfs (ansible/puppet/etc.) will need to adapt to that.

Comment 1 Colin Walters 2017-12-14 14:09:55 UTC

See also:

https://github.com/systemd/systemd/pull/7631
https://github.com/projectatomic/rpm-ostree/issues/550

Comment 2 James (purpleidea) 2017-12-15 03:43:26 UTC

Assuming this actually happens in the packaging, then this is definitely a bug!

(I personally don't know why I never noticed this before when doing all the GlusterFS things I've been involved in, but happy to +1 this.)

In fact, if services *do* autostart with package installation, this can break many config management modules (eg: puppet) and orchestrators as well (such as ansible).

Comment 3 Kaleb KEITHLEY 2017-12-19 16:51:15 UTC

I am quite familiar with the Fedora policy of not starting services during install.

I just did a fresh install of glusterfs-3.13.0-1 (including -server and -cli, etc.) on a pristine f28/rawhide box and glusterd was not started.

If a previous version was installed and running and you did an upgrade to 3.13.x, the upgrade may run gluster to update the volfiles (and then exit).

You need to provide more details about what you did. There's not enough info here for me to tell otherwise.

Comment 4 Kaleb KEITHLEY 2018-01-11 12:41:05 UTC

no response to needinfo.  glusterd.service is _not_ enabled or started. (It is, as noted above, run briefly to update volfiles.)

Closing, if reporter wishes to respond to the needinfo then go ahead and reopen.

Comment 5 Red Hat Bugzilla 2023-09-14 04:14:16 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days