On Sep 25, 2010, at 7:34 AM, Christian wrote: > Hello community, > > As you all know a good infrastructure deployment in production state > should not involve much technical infrastructure staff anymore. > Routine work should be able to perform by the users themselfs who > should not know anything about the infrastructure implementation > details.
I see all sorts of things that could go wrong with this. Users could easily mess up computers so bad that you need to manually make puppet work again. One mistake with storedconfigs could crash your database. (Technically the database might not crash in the example I'm thinking of, but it would bloat the DB to hundreds of megs per node.) > Up to now i'm a bit lost to reach such an high level target with my > puppet and SVN setup. My aim is to define a role in the user team > which is responsible to update existing or checkin new files in the > SVN repository. > > Updated files in the SVN should be checked out automatically (wih > hooks) into my puppet specific folder structure (into the module path > the file corresponds to). New files should be reportet to the > infrastructure maintenance person who could write a new module or > modify existing modules. > > Up to know i already hold the whole puppet folder structure under > version control which looks similar like this > > - /manifests/ > - /templates/ > - /files/ > - /modules/ module1/ manifests > ... / files > / templates > /module2/ ... > > > The files to be distributed are stored in he module's file folder. > However this is no user friendly because the user does no know nothing > about manifests, templates and oher puppet specific stuff. > > The user would prefer only a file structure similar like this one: > > /CI1_name/files... > /C!2_name/<file1>, <file2> ... <filen> > ... > > So far so good. I'm aware that it is possible to set a specific module > files folder path for each module. That would enable me to organise > the files in a way the user would prefer. However i'm running here in > problems with the templating functionality which we definitifly want > to use. As far as i know <%tags%> must be defined and the version of > the files to be disribue on a specific node will be generated > automatically. The files checked in by the users represents a specific > entity of the file represented in the template (For example differs in > the server name a client application should connect to).Therefore i > guess there must be probably a post commit script which introduces the > tags automatically in the updated file... I've never even heard of this idea. I don't say it's impossible, but I don't see an automatic solution doing anything more than searching the document for values given by factor and replacing it with the facter erb code. Something like this: 1) Get a value from facter (hostname=client2.localdomain) 2) Search the document for "client2.localdomain" and replace with "<%=hostname%>" 3) Repeat for every facter value You could do that, but you'd need the facter values from the host you got the file from. Also, I think it would be VERY error prone and nasty, but I don't see a better algorithm. Even this one would probably need someone to hand vet the files for stupid mistakes. Can you write a better algorithm? (In pseudo code) > Has somebody already tried to design a similar architecture like that > or are there in general better ways to achieve this high level goals? > Is the process i described above used in the real world already... ? At the very least, I can't see any way around needing all changes to the repository to be approved by someone you trust to prevent really bad mistakes. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
