Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-14441

Appliance: Minion fails to come up with 30.x and bleeding image



    • Bug
    • Status: Resolved (View Workflow)
    • Blocker
    • Resolution: Fixed
    • 30.0.1, 31.0.0
    • 30.0.1
    • Minion
    • Security Level: Default (Default Security Scheme)
    • Horizon 22 - Jun 23 - Jul 7


      Appliance: Minion container fails to come with 30.x and bleeding image.




      The OpenNMS Minion appliance launched a minion docker container.

      The appliance (dominion) uses a local and passive minion health-check query every 5 seconds as a readiness check.  If after 5 minutes, a successful response has not been returned, dominion respawns the minion container.

      With the latest release-30x and bleeding images, the Minion is in a respawn loop because dominion gets a 401 response to the minion health-check.

      j-white pointed to this issue having been introduced by https://github.com/OpenNMS/opennms/pull/4885.
      This PR added some explicit dependences on the JCEKS implementation of SCV, which made it's way down to Minion
      Minion in the appliance, actually changes the SCV implementation to be gRPC-based, and it feeds it credentials from there, so the JCEKS implementation is not present, and we see this problem
      here's the alternate SCV implementation for reference: https://github.com/OpenNMS/opennms/blob/develop/features/scv/dominion-grpc-impl/src/main/resources/OSGI-INF/blueprint/blueprint.xml#L26
      That code path isn't actually used on Minion (it doesn't connect to the DB), so we may be able to work around with with some OSGi wiring or bundle header changes


      This issue blocks the release of the next H30 release.





            cpape Christian Pape
            chantal Chantal Moffatt
            0 Vote for this issue
            2 Start watching this issue