SUSE Manager/ActionChaining

From MicroFocusInternationalWiki
Revision as of 17:33, 29 January 2014 by SilvioMoioli (Talk | contribs) (Definitions)

Jump to: navigation, search


Some operations available in SUMa should really be executed in sequence. Provide a way to schedule a sequence of such operations for a system or a set of systems.

User stories

Scenario: a complex patching routine

As an administrator, I want to execute an update procedure on web servers to fix a security issue

  • from the System List page, I select systems that I want to update
  • from the SSM Provisioning/Run Command page:
    • I input a script to stop services that are going to be updated
    • I select "Add to Action Chain" instead of the scheduling time and I input a new action chain name
  • from the Patches (Errata) page:
    • I select a patch to install
    • I select "Add to Action Chain", and I select the previous action chain name
  • from the Misc/Reboot page:
    • I select all systems in the set
    • I select "Add to Action Chain", and I select the previous action chain name
  • from the Action Chains page:
    • I check the correctness of the Action Check
    • I click on Execute Action Chain

Scenario: editing an Action Chain

As an administrator, I want to correct a mistake in an Action Chain to be able to execute it later

  • from the Action Chains page:
    • I select a chain that was previously created
    • I change the order of Actions in the Chain
    • I click on Save

Additional scenarios

  • deleting a system from an Action;
  • deleting an Action from a Chain;
  • deleting an Action Chain;


A supported operation is one of:

  • Install a package;
  • Update a package;
  • Remove a package;
  • Verify a package;
  • Apply a patch ("errata");
  • Run a command ("remote command");
  • Deploy a configuration file;
  • Reboot;

An Action is one of the supported operations applied to one or a set of systems.

An Action Chain is an ordered sequence of Actions.

The execution of an Action is the execution of its supported operation to all the systems it applies to.

The execution of an Action Chain is the execution of all its Actions, provided that:

  • if more than one Action applies to a same system, corresponding supported operations will be executed sequentially in Action Chain order.
  • if a supported operation fails on a system, no further supported operations will be executed.

Note that no ordering guarantees are made across systems.

User Interface Mockups

User interface for this feature is composed of:

  • an extra "Add to Action Chain" option in supported operation pages (HTML mockup);
  • a new page that lists Action Chains (HTML mockup);
  • a new page to edit an Action Chain (HTML mockup);

Note: HTML mockups have some working parts (eg. the combobox in the first one, dragging and dropping actions in the last one), but most links to other pages are disabled.

Screenshots of the proposed the User Interface are also available on inVision, SUSE employees can also leave comments (email smoioli at suse dot de if you don't have the permission to do so).

Implementation details

  • database tables need to be added to store user-editable Action Chains and Actions. Those will hold a reference to rhnaction (supported operation) and rhnserver (system);
  • executing an action will basically result in inserting appropriate lines in rhnserveraction (where they can be picked up by clients). Will also update rhnaction.prerequisite using the previous action id in the chain;
  • both single-system and SSM pages will be adapted to accept Action Chains as a schedule;
  • single-system reboot will be ported from Perl to Java (reboot_confirm.pxt);
  • a solution needs to be implemented in order to allow actions after a reboot - current implementation will likely pick up actions after having issued the shutdown command. If that is not feasible, reboot will be accepted exclusively as the last Action in a chain;
  • SSM code needs to be adapted, where necessary, to create one row in rhnaction per server. Currently part of SSM code does that, while part uses one action with multiple servers;
  • API calls will be added to perform WebUI-equivalent tasks.

Proposed combobox libraries:

Note that a true combobox is needed, not merely a dropdown, to allow selection of existing Action Chains as well as creation of new ones.

Currently discarded alternatives:

  • plain jQuery with both a dropdown and a textbox: simpler to implement but requires more clicks and takes more screen space;
  • autocompletition via HTML5 datalist or widgets (jQuery autocomplete, typeahead.js, etc.), as they do not show the list without knowing at least a character, or they do so without an obvious UI clue (eg. button with arrow pointing down);
  • chosen: simpler but does not support adding new elements. There is a pull request for that but it's years old, so it will probably never be supported;
  • bootstrap-combobox: no adding here either;
  • jQuery UI autocomplete combobox: incomplete and unsupported.

Drag-and-drop libraries:

  • jQuery-UI;