Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 0.9.0
    • Component/s: core
    • Labels:
      None

      Description

      I think we should persist the cluster spec .properties (or .yaml later) file as cluster state information. This is going to be really useful when trying to find the differences between the the currently running cluster and the one describe by the configuration file. This should allow us to have a nice implementation for a "converge" action.

        Issue Links

          Activity

          Hide
          Tom White added a comment -

          Paul - it sounds like this could be done by moving ~/.whirr/<cluster-name> to ~/.whirr/_terminated/<cluster-name>. Keeping logs in the cluster directory is a good idea too. I think both of these are a different JIRA to this one though.

          Show
          Tom White added a comment - Paul - it sounds like this could be done by moving ~/.whirr/<cluster-name> to ~/.whirr/_terminated/<cluster-name>. Keeping logs in the cluster directory is a good idea too. I think both of these are a different JIRA to this one though.
          Hide
          Paul Baclace added a comment -

          When I use Whirr, I compose whirr.config (common stuff + variable stuff + derived stuff) where derived stuff is calculated from variable stuff like type of machine.

          During post-processing when Whirr finishes, I "cp -r" the directory Whirr created and copy the composed whirr.config into it so I can keep notes about a run.

          It would be nice to have this built-in ("keep instead of remove after terminated"). I also have a snapshot mechanism that captures a tar-gz of a list of files relative to / to capture config files "as built". That way I can examine them after the ensemble is terminated.

          As mentioned in another jira item the instances file generated by Whirr can be used for reference and to avoid expensive ec2 api (or other provider equiv) calls.

          Log output of Whirr is best kept in the directory it generates.

          Whirr cluster destroy can touch a file "_Terminated" after termination.

          Show
          Paul Baclace added a comment - When I use Whirr, I compose whirr.config (common stuff + variable stuff + derived stuff) where derived stuff is calculated from variable stuff like type of machine. During post-processing when Whirr finishes, I "cp -r" the directory Whirr created and copy the composed whirr.config into it so I can keep notes about a run. It would be nice to have this built-in ("keep instead of remove after terminated"). I also have a snapshot mechanism that captures a tar-gz of a list of files relative to / to capture config files "as built". That way I can examine them after the ensemble is terminated. As mentioned in another jira item the instances file generated by Whirr can be used for reference and to avoid expensive ec2 api (or other provider equiv) calls. Log output of Whirr is best kept in the directory it generates. Whirr cluster destroy can touch a file "_Terminated" after termination.

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrei Savu
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development