order items inside bundles

[somekool <[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'>
etc...

thanks

[gdhagger]

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'>
        <Depends>
            <Package 'httpd'/>
        </Depends>
    </Path>
    <Service name='httpd'>
        <Depends>
            <Package 'httpd'/>
            <Path '/etc/httpd/conf/httpd.conf'/>
        </Depends>
    </Service>
</Bundle>

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.

[https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc]

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'/>

</Path>

</Service>

</Bundle>

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.

[https://www.google.com/accounts/o8/id?id=AItOawnhw7cCTB9JhH6_fsRONCTAzPmTAwS_BTc]

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:

​http://www.infrastructures.org/papers/turing/turing.html

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.