While I was working on Travis CI tests, I noticed that pkispawn -s KRA was failing regularly. It looks like pkispawn -s CA returns before the tomcat instance is ready to serve requests. Travis CI spawn a KRA directly after CA with no delay. Tests are now using a polling loop with curl and sleep. It usually takes 2 to 3 seconds until curl http://localhost:8080 works.
pkispawn -s KRA
pkispawn -s CA
curl http://localhost:8080
$ pkispawn -f /tmp/workdir/pki/.travis/pki.cfg -s KRA Log file: /var/log/pki/pki-kra-spawn.20170418062853.log Loading deployment configuration from /tmp/workdir/pki/.travis/pki.cfg. ERROR: Unable to access security domain: HTTPSConnectionPool(host='pki.test', port=8443): Max retries exceeded with url: /ca/rest/securityDomain/domainInfo (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f05cedb3210>: Failed to establish a new connection: [Errno 111] Connection refused',))
pkispawn should use wait_for_startup to wait until Tomcat is ready before it exits.
wait_for_startup
Unfortunately, a bug in "Pagure" does not allow one to specify the PKI "default" Milestone "0.0 NEEDS_TRIAGE"; as a consequence bugs coming in without Milestones may not be "discovered" initially.
Filed https://pagure.io/pagure/issue/2246 - [RFE] - Ability to programmatically specify "default" Milestone
Metadata Update from @mharmsen: - Custom field component adjusted to General - Custom field feature adjusted to '' - Custom field origin adjusted to Community - Custom field proposedmilestone adjusted to '' - Custom field proposedpriority adjusted to '' - Custom field reviewer adjusted to '' - Custom field type adjusted to defect - Custom field version adjusted to '' - Issue set to the milestone: 0.0 NEEDS_TRIAGE
Thanks Matt, I'll keep the issue in mind for future tickets.
Metadata Update from @mharmsen: - Issue priority set to: ---
Per PKI Bug Council of 04/27/2017: cheimes will provide a patch for this issue
Metadata Update from @mharmsen: - Issue priority set to: critical (was: ---) - Issue set to the milestone: 10.4 (was: 0.0 NEEDS_TRIAGE)
Metadata Update from @mharmsen: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1446364
Issue linked to Bugzilla: Bug 1446364
Hi. What is the status on this issue? I run into dogtag not responding in most of our freeipa multihost tests with replication scenarios, literally blocking execution of tests in our CI as well as skewing a lot of results when I have to abort the stuck jobs. The actual cause for my issue matches more #2646 but that one is probably just a different manifestation of this issue.
Pushed to master c0bb0ee8e36a85673e30352a7205414b215196a5
cheimes made the following check-in:
commit c0bb0ee8e36a85673e30352a7205414b215196a5 Author: Christian Heimes <cheimes@redhat.com> Date: Mon May 8 18:53:26 2017 +0200 pkispawn: wait after final restart The finalization scriptlet now waits after service has been restarted. Change-Id: Id462728386b9d7e6b3364e1651ef6676115dd1de Bugzilla: BZ#1446364 Pagure: 2644 Signed-off-by: Christian Heimes <cheimes@redhat.com>
Metadata Update from @mharmsen: - Issue close_status updated to: fixed - Issue set to the milestone: 10.4.4 (was: 10.4) - Issue status updated to: Closed (was: Open)
Metadata Update from @mharmsen: - Issue assigned to cheimes
Metadata Update from @mharmsen: - Custom field fixedinversion adjusted to pki-core-10.4.1-4.el7
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2764
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.