Uploaded image for project: 'Mesos'
  1. Mesos
  2. MESOS-8693

agent: update_resource_provider w/ identical RP info should not always force-restart plugin

    XMLWordPrintableJSON

Details

    • Task
    • Status: Resolved
    • Major
    • Resolution: Duplicate
    • 1.5.0
    • None
    • None

    Description

      Currently when the UPDATE_RESOURCE_PROVIDER call is sent to an agent, and the RP info of the request is identical to that of the running configuration, the agent force-restarts the related CSI plugin. This is surprising on two accounts:

      First, because it increases the complexity of the client that wants to ensure the latest RP configuration is pushed to the agent. A CSI plugin may take a long time to become ready after being reconfigured. It's likely that a caller will experience a timeout while waiting for the RP to come into a healthy state w/ the desired configuration. Upon retrying the update, a client DOES NOT always wish to restart an ongoing reconfiguration effort – especially when for long running reconfiguration operations. Mesos should NOT restart the related CSI plugin by default if the new RP info matches the existing one, and instead should either return 409 or some other, more appropriate error code (409 would be nice/consistent, see below).

      Second, because it differs from the idempotent nature of the ADD_RESOURCE_PROVIDER call, which does NOT change the state of the plugin in case of a duplicate request. The ADD_RESOURCE_PROVIDER call returns a 409 response, which allows callers to simply re-issue redundant requests without concern for interrupting the state of a running plugin.

      In the event that caller DOES want to force the restart of an underlying CSI plugin, I suggest that we extend the UPDATE_RESOURCE_PROVIDER call w/ a "force_restart" field (sibling to the "info" field). "force_restart == true" would only have meaning for updates that involve unchanged RP info, otherwise it would go unused.

      /cc jieyu chhsia0

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              jdef James DeFelice
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: