Puppet broke my Xen

Actually it didn't , but now I got your attention.
We just adopted the use of adding headers to all of our files that are managed by puppet so people will know not to touch it

  file {
                "/etc/xen/scripts/network-custom-vlan-bridges":
                        owner => "root",
                        group => "root",
                        mode => "0755",
                        content => template(
                                "headers/header-hash.erb',
                                "xen/co-mmx-network-custom-vlan-bridges.erb");
        }

All worked nice however upon bootstrapping our Xen host the bridges stopped working .. running the network-custom-vlan-bridges script manually solved everything and created the appropriate bridges. But at boottime it didn't..

I added some debug info to the script and figured it never got executed at boot time.

Turns out that when I removed the headers Xen actually does configure the bridges at boot time, Xen probably checks for a shebang at the beginning of the file.

Putting the header at the end of the file therefore solved the problem. ,

Submitted by Kris Buytaert on Sat, 10/30/2010 - 16:35

Tags:

Kris Buytaert's blog

Comments

#1 loupgaroublond : why not just?

Why not just put the shebang in first, then the headers?

Is there anything else that might conceivably need to go into the headers besides a shebang that has to go before the real headers? I've used automated scripts for doing headers in the past, since coworkers forget to update them. (We also linked back to the original location in SVN, so the same coworkers could find the files there.)

10/30/2010 - 22:32

#2 Kris Buytaert : Because then we need build

Because then we need build some kind of intelligent merge system that detects what kind of file it is and then depending on the type decides both which type of comment and where to put it eg in this case after the shebang.

Don't you think that's kind of overkill ? :)

10/31/2010 - 09:50

#3 Matt : header at the end of a file

... the only disadvantage about having the header "do not touch" at the end of a file is that nobody will read it hehehe.

greetz + stay tuned,

Matt

10/30/2010 - 18:21

#4 Nigel Kersten : Imagine if we didn't need to

Imagine if we didn't need to do this sort of header work, and could somehow integrate into a filesystem event model where you could alert people interactively if they were making modifications that clashed with the client catalog....

10/30/2010 - 21:28

#5 Dan Carley : There's a good vim plugin

There's a good vim plugin that tackles this issue from a slightly different angle: TangledStrings.

11/01/2010 - 12:30

#6 Kris Buytaert : That would be a perfect

That would be a perfect solution if only everybody that is allowed on the machine actually used vi ...

11/01/2010 - 13:32

#7 Nigel Kersten : Update: Filed

Update: Filed http://projects.puppetlabs.com/issues/5158 and sent a mail to puppet-users to provoke some discussion.

Input always welcome.

10/30/2010 - 17:47

#8 Nigel Kersten : concatenating templates...

so you're one who uses the concatenating templates functionality...

I think we have a usability problem we're going to have to address, which is that the source parameter and template functions behave entirely differently when you provide an array of items.

The source parameter walks the array until it finds an item that exists, but the template function concatenates.

Do you use the concatenating of templates a lot in your manifests? Would you find it horribly annoying if you had to do the header work in your templates themselves?

I really would like us to make the source parameter, file function and template function behave consistently, but unfortunately it appears people use all the inconsistent behavior.

10/30/2010 - 17:21