Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1097247

Summary: New Pulp services don't output proper status
Product: [Retired] Pulp Reporter: Eric Helms <ehelms>
Component: API/integrationAssignee: Randy Barlow <rbarlow>
Status: CLOSED CURRENTRELEASE QA Contact: Irina Gulina <igulina>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 2.4 BetaCC: igulina, ipanova, rbarlow, skarmark
Target Milestone: ---Keywords: Triaged
Target Release: 2.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-09 06:57:02 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 Flags
verifiyng screenlog over RHEL6.5 none

Description Eric Helms 2014-05-13 12:37:21 UTC
The three new services introduced by Pulp 2.4 (pulp_celerybeat, pulp_resource_manager, pulp_workers) are not independent and don't return usable status when trying to automate their usage. 

 * pulp_celerybeat - no status
 * pulp_resource_manager - returns the status of all three services
 * pulp_workers - returns the status of all three services

For example, if I start pulp_celerybeat and attempt to check the status of pulp_workers I will receive a '0' exit code when running 'service pulp_workers status' because the pulp_workers status returns the status of all three. This means that attempts to automate starting and stopping of service based on their status (e.g. using puppet) is more complex as custom parsers must be written to determine the status of each. If nothing else, they are independent services and should only report about themselves given that other commands (start, stop, restart) control only that service.

Comment 1 Randy Barlow 2014-05-22 18:13:43 UTC
https://github.com/pulp/pulp/pull/985

Comment 2 Randy Barlow 2014-05-29 18:07:28 UTC
This was fixed in pulp-2.4.0-0.19.beta.

Comment 3 Irina Gulina 2014-06-12 11:56:54 UTC
>>rpm -qa pulp*
pulp-rpm-admin-extensions-2.4.0-0.20.beta.fc20.noarch
pulp-rpm-handlers-2.4.0-0.20.beta.fc20.noarch
pulp-selinux-2.4.0-0.20.beta.fc20.noarch
pulp-admin-client-2.4.0-0.20.beta.fc20.noarch
pulp-agent-2.4.0-0.20.beta.fc20.noarch
pulp-rpm-yumplugins-2.4.0-0.20.beta.fc20.noarch
pulp-server-2.4.0-0.20.beta.fc20.noarch
pulp-consumer-client-2.4.0-0.20.beta.fc20.noarch
pulp-puppet-handlers-2.4.0-0.20.beta.fc20.noarch
pulp-puppet-consumer-extensions-2.4.0-0.20.beta.fc20.noarch
pulp-puppet-plugins-2.4.0-0.20.beta.fc20.noarch
pulp-puppet-admin-extensions-2.4.0-0.20.beta.fc20.noarch
pulp-rpm-consumer-extensions-2.4.0-0.20.beta.fc20.noarch
pulp-rpm-plugins-2.4.0-0.20.beta.fc20.noarch

>> service pulp_celerybeat status
Redirecting to /bin/systemctl status  pulp_celerybeat.service
pulp_celerybeat.service - Pulp's Celerybeat
   Loaded: loaded (/usr/lib/systemd/system/pulp_celerybeat.service; enabled)
   Active: active (running) since Wed 2014-06-11 16:31:46 UTC; 19h ago
 Main PID: 19788 (celery)
   CGroup: /system.slice/pulp_celerybeat.service
           └─19788 /usr/bin/python /usr/bin/celery beat --scheduler=pulp.server.async.scheduler.Scheduler

>>service pulp_resource_manager status 
pulp_resource_manager.service - Pulp Resource Manager
   Loaded: loaded (/usr/lib/systemd/system/pulp_resource_manager.service; enabled)
   Active: active (running) since Thu 2014-06-12 11:44:34 UTC; 7s ago
 Main PID: 5702 (celery)
   CGroup: /system.slice/pulp_resource_manager.service
           ├─5702 /usr/bin/python /usr/bin/celery worker -A pulp.server.async.app -n resource_manager@%h -Q resource_manager -c 1 --events
           └─5711 /usr/bin/python /usr/bin/celery worker -A pulp.server.async.app -n resource_manager@%h -Q resource_manager -c 1 --events


>>service pulp_workers status
Redirecting to /bin/systemctl status  pulp_workers.service
pulp_workers.service - Pulp Celery Workers
   Loaded: loaded (/usr/lib/systemd/system/pulp_workers.service; enabled)
   Active: active (exited) since Wed 2014-06-11 16:31:46 UTC; 19h ago
 Main PID: 19765 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/pulp_workers.service


Tried other commands (start, stop, restart) and it controled only a specified service.

Verified.

Comment 4 Randy Barlow 2014-06-12 15:50:13 UTC
Hi Irina,

This bug wasn't very clear now that I look back at it, but the original issue that was reported was about our init scripts having working status commands that set correct exit codes. I noticed that you verified our systemd units here. Can you retest on RHEL 6, which uses the init scripts instead of the systemd units? Apologies for not making that clear before you verified it!

Comment 5 Irina Gulina 2014-06-16 14:23:23 UTC
Created attachment 909150 [details]
verifiyng screenlog over RHEL6.5

status reported by services is mutually independent

Comment 6 Randy Barlow 2014-08-09 06:57:02 UTC
This has been fixed in Pulp 2.4.0-1.