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.
