Uploaded image for project: 'MCollective'
  1. MCollective
  2. MCO-777

mco doesn't distinguish between responses from discovered nodes and unexpected responses

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: MCO 2.10.0
    • Component/s: None
    • Labels:
    • Template:
    • Acceptance Criteria:
      Hide

      It should be possible to identify nodes that responded to an rpc request but not discovery, and those nodes should not impact reporting results of nodes that responded to discovery.

      Show
      It should be possible to identify nodes that responded to an rpc request but not discovery, and those nodes should not impact reporting results of nodes that responded to discovery.
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      Nodes that responded to an rpc request but not discovery will now be called out in an "unexpected response" section. Those nodes will no longer impact reporting results of nodes that responded to discovery, meaning the run will now wait for all discovered nodes to respond. This addresses a scenario where nodes didn't respond to discovery, but responded to the rpc request and caused a node that was discovered to be reported in the "no response" section.
      Show
      Nodes that responded to an rpc request but not discovery will now be called out in an "unexpected response" section. Those nodes will no longer impact reporting results of nodes that responded to discovery, meaning the run will now wait for all discovered nodes to respond. This addresses a scenario where nodes didn't respond to discovery, but responded to the rpc request and caused a node that was discovered to be reported in the "no response" section.

      Description

      When performing an rpc action with mco, sometimes nodes fail to respond to discovery in a timely fashion but then respond to the actual request. This can result in confusing output. For example, running mco puppet status might look like

      0 / 5
      1 / 5
      2 / 5
      3 / 5
      4 / 5
      5 / 5
       
                      foo1.example.com: Currenty idle ; last completed run 1 minutes 04 seconds ago
                      foo2.example.com: Currenty idle ; last completed run 1 minutes 05 seconds ago
                      foo4.example.com: Currenty idle ; last completed run 1 minutes 07 seconds ago
                      foo6.example.com: Currenty idle ; last completed run 1 minutes 09 seconds ago
                      foo7.example.com: Currenty idle ; last completed run 1 minutes 10 seconds ago
       
      ...
       
      No response from:
       
          foo3.example.com foo5.example.com
      

      What happened is foo3 and foo5 responded to the discovery, while 2 nodes (we're not sure which, but for simplicity I'll say it was foo6 and foo7) didn't respond to discovery; that meant we expected 5 nodes to respond to the rpc request. However all 7 nodes respond to the request, but since mco only expects 5 responses it drops the last 2.

      This output should be improved so we wait for responses from all the nodes initially discovered, continue to report responses that were expected but missing (because the discovered nodes never responded to the rpc query), and report nodes that weren't discovered but successfully responded to the rpc query.

      The corollary - that nodes respond to discovery but don't respond to the rpc request - is already covered by the existing behavior.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                qa qa
                Reporter:
                michael.smith Michael Smith
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support