Bug 1384756

IMHO, for any optional package we have to be strict on bringing up the service by default on installation. Aravinda - What's your thought?

(In reply to Atin Mukherjee from comment #2)
> IMHO, for any optional package we have to be strict on bringing up the
> service by default on installation. Aravinda - What's your thought?

s/we have/we don't have to

(In reply to Atin Mukherjee from comment #3)
> (In reply to Atin Mukherjee from comment #2)
> > IMHO, for any optional package we have to be strict on bringing up the
> > service by default on installation. Aravinda - What's your thought?
> 
> s/we have/we don't have to

IMO, we should restrict optional at package layer. Once the optional package is installed, it is good to start the daemon services inherit by the optional package

(In reply to Rahul Hinduja from comment #4)
> (In reply to Atin Mukherjee from comment #3)
> > (In reply to Atin Mukherjee from comment #2)
> > > IMHO, for any optional package we have to be strict on bringing up the
> > > service by default on installation. Aravinda - What's your thought?
> > 
> > s/we have/we don't have to
> 
> IMO, we should restrict optional at package layer. Once the optional package
> is installed, it is good to start the daemon services inherit by the
> optional package

glusterfs-events will be a optional package. I guess Aravinda has already fixed that part. Coming to the other part of it, are you saying once the optional package is installed the service should be started by default (not manually)?

Currently: 

If we are not enabling manually, glustereventsd won't start after node reboot.
so to start after every node reboot we have to enable it using systemctl enable glustereventsd 


Expected is: after installation of glusterfs-events, this should get enabled automatically similar to glusterd, for which  we won't enable manually any time ( update/upgrade/fresh install )


About service starting:
glustereventsd service  should not start default ( automatically ) after installation, user has to start it (for fresh installation ) OR restart it ( for update/upgrade )

It showing "disabled" after installation of glusterfs-events pkg.

 ~]# systemctl is-enabled glustereventsd
disabled

Fedora packaging guidelines says we should not enable services by default

"If a service should be enabled by default, make this the default in the init script. Doing otherwise will cause the service to be turned on on upgrades if the user explicitly disabled it. "

Ref: http://fedoraproject.org/wiki/EPEL:SysVInitScript#Why_don.27t_we....

(In reply to Aravinda VK from comment #8)
> Fedora packaging guidelines says we should not enable services by default
> 
> "If a service should be enabled by default, make this the default in the
> init script. Doing otherwise will cause the service to be turned on on
> upgrades if the user explicitly disabled it. "
> 
> Ref: http://fedoraproject.org/wiki/EPEL:SysVInitScript#Why_don.27t_we....

glusterfs-server package enables the glusterd service while updating in the downstream and not in the upstream, we want to the same change for this events daemon in the downstream.

Let user take the action to disable it explicitly after update if user don't want to enable it.

(In reply to Byreddy from comment #9)
> (In reply to Aravinda VK from comment #8)
> > Fedora packaging guidelines says we should not enable services by default
> > 
> > "If a service should be enabled by default, make this the default in the
> > init script. Doing otherwise will cause the service to be turned on on
> > upgrades if the user explicitly disabled it. "
> > 
> > Ref: http://fedoraproject.org/wiki/EPEL:SysVInitScript#Why_don.27t_we....
> 
> glusterfs-server package enables the glusterd service while updating in the
> downstream and not in the upstream, we want to the same change for this
> events daemon in the downstream.
> 
> Let user take the action to disable it explicitly after update if user don't
> want to enable it.

I am sorry but I don't understand this difference. Could you elaborate? And I disagree on the 2nd point.

(In reply to Atin Mukherjee from comment #10)
> (In reply to Byreddy from comment #9)
> > (In reply to Aravinda VK from comment #8)
> > > Fedora packaging guidelines says we should not enable services by default
> > > 
> > > "If a service should be enabled by default, make this the default in the
> > > init script. Doing otherwise will cause the service to be turned on on
> > > upgrades if the user explicitly disabled it. "
> > > 
> > > Ref: http://fedoraproject.org/wiki/EPEL:SysVInitScript#Why_don.27t_we....
> > 
> > glusterfs-server package enables the glusterd service while updating in the
> > downstream and not in the upstream, we want to the same change for this
> > events daemon in the downstream.
> > 
> > Let user take the action to disable it explicitly after update if user don't
> > want to enable it.
> 
> I am sorry but I don't understand this difference. Could you elaborate? And
> I disagree on the 2nd point.


while installing upstream glusterfs-server package, it won't enable the glusterd by default, user has to enable it explicitly after installing and while installing downstream glusterfs-server package, it enables the glusterd by default.

We need carry the same behavior for glustereventsd as well.

Aravinda, Byreddy - can we come to a conclusion on this, my take is not enable the service by default.

(In reply to Atin Mukherjee from comment #12)
> Aravinda, Byreddy - can we come to a conclusion on this, my take is not
> enable the service by default.

From My side: we have to enable for glustereventsd in the downstream because we are enabling for glusterd in the down stream.

@Atin, Pls want to know why we are enabling for glusterd in the down stream, if any specific reason is there to enable ?

From my understanding, we are enabling glusterd service to start the service after every node reboot.

@Aravinda, Pls add your input here.

@Byreddy - glusterd is a mandatory service for other daemons to be controlled. On a node reboot, if you end up not starting glusterd service automatically you'd not be able to bring up other daemons like brick process, shd, quota etc which would defeat the purpose. What I am failing to understand here is why are we comparing glustereventsd (optional package) with glusterd (mandatory)?

glusterd and glustereventsd are independent daemon services which we can start/stop using systemctl BUT we can't start/stop bricks processes, shd, quota, etc using systemctl, which are controlled by glusterd.

Enabling the service should not depend on the package type (optional/mandatory) 

If end user want to use any optional package, what ever the service it will create, it should enable while installing.

Upstream patch sent to fix the issue. http://review.gluster.org/#/c/15853

Packaging guidelines suggest not to enable a service by default after installation. Closing this bug as this is the expected behavior. Please reopen if this is still a issue.