Issue #6911 has been updated by Markus Roberts.
Branch set to MarkusQ:feature/next/resource_application_order
Core change up for review. Note that is *not* a resolution, just a key
way-point on the route to a resolution.
(6911) Core change -- replace topsort with frontier ordered by salted SHA1
This is the core change of the ticket; rather than using a topological sort
to statically
determine the order in which resources should be applied, we use the graph
wrapper
introduced in the prior commit to dynamically determine the order in which
to apply
resources based on 1) the status of the resource (ready, done) 2) the
explicit &
implied dependencies, 3) the salted SHA1 of the title (for stability).
Further work is needed:
1) Resolving the handling of failed resources
2) Tests of the new behavior, to the extent possible
3) Newly-dead-code removal in simple_graph & transaction
4) Fix the name-prefix ordering hack in eval_generate by either:
a) Moving the logic into file
b) Refactoring Type#eval_generate to return a tree
c) ....?
5) Rough performance testing to look for hotspots
6) Investigation of possible interaction with #3788, #5351, #5414, #5876,
#6020, #6810,
and #6944 which may simplify or complicate their resolution.
Paired-with: Jesse Wolfe
----------------------------------------
Feature #6911: Flexible, deterministic, unguessable application order
https://projects.puppetlabs.com/issues/6911
Author: Markus Roberts
Status: Accepted
Priority: Normal
Assignee: Markus Roberts
Category:
Target version: Statler
Affected Puppet version:
Keywords:
Branch: MarkusQ:feature/next/resource_application_order
We would like to change the order in which resources are applied to meet a very
specific set of constraints:
1. The order should permit responsive adaptation to externalities (graph
frontiers)
2. The order in which resources that do not depend on externalities should be
consistent (deterministic) from run to run provided that no structural changes
occur in the manifest
3. Changes in the ordering due to manifest changes should be limited in scope
and correspond to the areas that were changed (that is,
adding/removing/changing one resource should not affect the relative order of
any unrelated pair of resources)
4. It should not be possible to guess the ordering a priori -- this mechanism
is not a substitute for declaring dependencies.
5. It should not violate any implicit or explicit dependencies
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
