Design notes for porting redeployment of affected deployments of an overlay to the server side

Version 8

    User story

    When a deployment overlay changes it would be nice to be able to redeploy those deployments that are affected by this overlay so that the changes are easily visible.

    Currently this was done on the client side by the CLI but it was not working properly and after some changes it still couldn't be used in a batch as some changes wouldn't be visible when the operation is executed on the CLI.

    So the idea is to be able to compute and  redeploy those deployments on the server side.

     

    Issue metadata

    [WFCORE-1752] The deployment-overlay command fails to redeploy affected deployments - JBoss Issue Tracker

     

     

    Hard requirements

    Be able to redeploy affected deployments in standalone and domain mode passing a list of runtime-names or an empty or undefined list if we want to redeploy ALL the affected deployments.

    So we should have a redeploy-links operation with a deployments optional parameter on overlays.

    If we are referencing a deployment that is not linked to the overlay then the operation will fail before even starting the redeployments.

    This is wrong as an overlay may refer to unexisting deployments, so the high level operation from the CLI might pass an unexisting deployment name which would break the final operation (aka the built composite from the CLI).

    When removing a 'link' to a deployment we could ask to redeploy the affected deployment with the "redeploy-affected" flag.

     

    So in standalone the operations would be :

     

    /deployment-overlay=foo:redeploy-links(deployments={foo.war, bar/ear})
    /deployment-overlay=foo/deployment=bar.war:remove(redeploy-affected)
    

     

    In domain mode we would have the operation available on domain root and at the server-group level of overlays. Thus that means tha the operation won't run on a slave HC.

    The domain root would apply the operation to all the server groups that are referencing the overlay while the server-group; operation would be restricted to the server-group (for the affected deployments).

    When removing a 'link' to a deployment we could ask to redeploy the affected deployment with the "redeploy-affected" flag.

    Thus we would have :

    * for server-groups

    /server-group=main/deployment-overlay=foo:redeploy-links(deployments={foo.war, bar/ear})
    /server-group=main/deployment-overlay=foo/deployment=bar.war:remove(redeploy-affected)
    

    * for domain root

    /deployment-overlay=foo:redeploy-links(deployments={foo.war, bar/ear})
    

     

    So it is up the the handler to read the current model to get the list of runtime names affected by an overlay (restrict it to the optional list passed as a parameter). From those runtime names compute the list of affected deployments and redeploy those.

     

    Not requirements

     

    We don't want to change the remove operation on overlays to redeploy the affected deployments as this is only a convenience over calling the removal of links with the redeploy-affected flag.