Puppet: System Administration Automated

Support

Ticket #625 (new enhancement)

Opened 2 years ago

Last modified 9 months ago

Convert 'ensure' to use a state machine

Reported by: luke Assigned to: community
Priority: normal Milestone: unplanned
Component: RAL Version:
Severity: normal Keywords: ral transaction statemachine
Cc: Triage Stage: Accepted
Attached Patches: None Complexity: Unknown

Description

See the specification at Resource State Machines.

Discussions with Allen Ballman got me far enough that I think we know what we're doing, and he's volunteered to work on the first step: Creating a module that can handle the state machine operations.

Backward compatibility is only 'limited' because it will involve some deprecation -- e.g., the 'enabled' property on services will likely go away, and instead most services are likely to have 'enabled' as a state between 'absent' and 'running'.

Change History

05/09/07 21:08:32 changed by luke

  • milestone set to elmo.

(follow-up: ↓ 3 ) 07/20/07 18:37:22 changed by luke

Note that this is related to #726. I defined mounts as having three states: absent, present, and mounted. Puppet will never mount a resource without first adding it to the fstab, but humans can do so, which confuses Puppet to no end.

Any state machine apparently needs to be able to deal with this situation, either by considering 'mounted' and 'present' related states somehow, or by testing all intermediate states and applying appropriately.

(in reply to: ↑ 2 ) 07/21/07 12:50:11 changed by DavidS

Replying to luke:

Note that this is related to #726. I defined mounts as having three states: absent, present, and mounted. Puppet will never mount a resource without first adding it to the fstab, but humans can do so, which confuses Puppet to no end. Any state machine apparently needs to be able to deal with this situation, either by considering 'mounted' and 'present' related states somehow, or by testing all intermediate states and applying appropriately.

To do this "by the book" you'd have to introduce states for every possible system configuration, correctly detect the current state and then proceed accordingly.

For easier modelling it would be easier in this case to have a separate model for the fstab and the mount itself and then acting on a combined state machine which uses [fstab_state, mount_state] tuples as states. The combined set of transitions is

for each fstab_transition (old_fstab_state, new_fstab_state):
   create_combined_transition ( [old_fstab_state, mount_state], [new_fstab_state, mount_state] )

for each mount_transition (old_mount_state, new_mount_state):
   create_combined_transition ( [fstab_state, old_mount_state], [fstab_state, new_mount_state] )

Some of theses tuples can then be labelled:

( absent, unmounted ) => :absent
( present, unmounted ) => :present
( present, mounted ) => :mounted

Unlabelled states cannot be reached with puppet, only "repaired". If no (known, complete) state is recognized, puppet can abort with an error.

07/22/07 21:29:53 changed by luke

This still seems like we're modeling three distinct states, they are just determined by two status values, rather than just one.

We need a fourth final state, though, for the "absent, mounted" tuple.

11/24/07 03:42:48 changed by luke

  • owner changed from ballman to community.
  • priority changed from high to normal.
  • milestone changed from elmo to unplanned.

Reducing the priority, since it's clearly not as high as plenty others.

04/24/08 07:46:12 changed by luke

  • component changed from library to RAL.