Ticket #837 (new enhancement)

Opened 13 years ago

Last modified 10 years ago

order items inside bundles

Reported by: somekool <[email protected]…> Owned by: desai
Priority: major Milestone: Bcfg2 1.4.0 Release
Component: bcfg2-server Version: 1.0
Keywords: Cc: gdhagger, [email protected]


to be able to automate installation of service properly by bcfg2, we definitly need to be able to set an ordering of items inside bundle.

right now, action can be set as 'pre' or 'post'

but we could need all configfile and packages and services to be set an order_id in the xml definition.

<bundler name=apache>
<configfile name='a' order='1'>
<configfile name='b' order='2'>
<package name='a' order='3'>
<package name='b' order='4'>



Change History

comment:1 Changed 13 years ago by solj

  • Milestone changed from Bcfg2 1.1.0 Release to Bcfg2 1.2.0 Release

comment:2 Changed 12 years ago by gdhagger

  • Cc gdhagger added
  • Type changed from defect to enhancement

While I don't wish to just copy from other conf mgmt tools, I like the way puppet handles ordering to a certain degree.

Basically, the way I see their methodology worked into Bcfg2's Bundler would be something like the following:

<Bundle name='apache'>
    <Package name='httpd'/>
    <Path name='/etc/httpd/conf/httpd.conf'>
            <Package 'httpd'/>
    <Service name='httpd'>
            <Package 'httpd'/>
            <Path '/etc/httpd/conf/httpd.conf'/>

Based upon this example, Bcfg2 would be able to work out the order of the elements involved. Also, as the service httpd was dependent on the config file, Bcfg2 would know to restart that service any time that config file was changed.

I'd be interested in taking a stab at this if it's agreed this is a good way to go forwards.

comment:3 Changed 12 years ago by

It seems like we could use the magic of XML parent-child relationships to accomplish this in a more lightweight fashion, e.g.:

<Bundle name='apache'>

<Service name='httpd'>

<Path name='/etc/httpd/conf/httpd.conf'>

<Package name='httpd'/>




The downside to this approach (as opposed to Graham's approach) is that you can't have multiple entries depend on one entry. But it would be a lot cleaner and lighter weight.

comment:4 Changed 12 years ago by solj

  • Milestone changed from Bcfg2 1.2.0 Release to Bcfg2 1.3.0 Release

comment:5 Changed 11 years ago by

Hi gdhagger, It looks like this ticket is still open, so I'd like to comment that"

I see what you're saying about letting a configurator automatically determine ordering based on dependencies, and I agree that automating this is good, but...

Puppet's lack of a deterministic ordering has been a serious problem for a number of sites, especially in production. While occasionally interesting in testing, where exposing an unexpected dependency is good, this is the last thing one wants in a production environment, and puppet's newly added determinism is weak (according to reports), only producing the same order for an nearly-unchanged configuration, and only predictable in the sense of having a record of the earlier run.

I suggest that Bcfg2 should have not just a repeatable serialization (like new puppet), but a fully deterministic, predictable serialization. Even a changed installation order of RPMs can break a system, and having that happen behind one's back over some other, apparently orthogonal change shatters the principle of least surprise. Being able to set it explicitly, as described by others in this thread, is handy, but the fallback still needs to be predictable.

There's a good paper on this problem at:

Why Order Matters: Turing Equivalence in Automated Systems Administration:

Several places I've worked *cannot* use Puppet over serialization issues, one of several reasons they're using Chef instead. I'm looking forward to using Bcfg2 instead of Chef, but we *have* to have defined ordering.

comment:6 Changed 10 years ago by solj

  • Milestone changed from Bcfg2 1.3.0 Release to Bcfg2 1.4.0 Release

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.


Add a comment

Modify Ticket

Change Properties
<Author field>
as new

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.