Puppet users - Sep 2010 - Best practice using puppet and SVN in a production environment

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.

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...

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... ?

Thanks a lot

Christian

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Sep 25, 2010 at 07:34:19AM -0700, 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 don''t think I agree with this, but nothing in your message makes it
clear what you mean by "users".  What kind of systems are you
managing,
what is the relationship between you and the users (are they people in
another department, customers or what?) and what are their skills?

-- 
Bruce

Hierophant: someone who remembers, when you are on the way down,
everything you did to them on the way up.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks for answering...

Sorry for beeing not precise enough.

In our environment we are working in a multidicipline domain.
Infrastructure staff and engineers are working in the same team. Users
of the system are engieers (not software engineers) able to understand
the pricipal and the basic usage of a version control system like SVN.
They are able to checkin and checkout themself and they in general
understand the riscs with could happen if they are checkin files with
bad content. The files they should checkin are basicly the files for
the user application layer and basicly not the OS layer which of
course stays under full control of the infrastructure.

We are managening a complex distributed control center (around 50
clients and 10 servers) including the installed user application.

Hope that makes things clearer...



On 26 Sep., 18:09, Bruce Richardson <itsbr...@workshy.org>
wrote:
> On Sat, Sep 25, 2010 at 07:34:19AM -0700, 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 don''t think I agree with this, but nothing in your message makes
it
> clear what you mean by "users".  What kind of systems are you
managing,
> what is the relationship between you and the users (are they people in
> another department, customers or what?) and what are their skills?
>
> --
> Bruce
>
> Hierophant: someone who remembers, when you are on the way down,
> everything you did to them on the way up.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.