----- "Trevor Vaughan" <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hmm, this seems like a good idea overall to me.
>
> Thinking about it, I think that stored configs has two main issues:
>
> 1) You can't selectively store things, it just stores everything (to
> my knowledge). It would be quite nice to be able to set refresh limits
> on things. I.e. refresh NIC information once a day, etc...
>
> 2) There doesn't seem to be a database cache on each node. I think
> that using a caching scheme (MySQL replication, replicated LDAP, ???) may
> alleviate most of the scaling issues with stored configs.
My plan is to use MCollective's registration system to feed the db. Not puppet.
That way even before puppet ever run once the node will already be in the
DB,facts available etc and I can easily distribute this to many geo dispersed
masters - very hard with puppets current way of doing this.
>
> I do like the idea of the hash-based access though.
>
> Trevor
>
> On 07/15/2010 06:22 AM, R.I.Pienaar wrote:
> > hello,
> >
> > I'm toying with attempting to build an alternate way to gain
> information about nodes. I don't personally find stored confs a good
> idea reasons thats OT for this post so need something else.
> >
> > I'll give a quick overview of what I want to build so you can
> understand the scope of my question. I essentially want to use a
> document database to store facts, classes list and some other
> information and then make that availble to puppet in a query system.
> >
> > in manifests:
> >
> > Get a list of all my centos/redhat machines, simple array gets
> returned:
> > $nodes = search("{'facts.operatingsystem' : { \$in: ['CentOS',
> 'Redhat']}}")
> >
> > For puppet 2.6 get a hash containing all the data for a node:
> > $node = node_data("{'hostname': '$name'}")
> >
> > in ruby manifests and templates:
> >
> > Util.search({"classes" => "apache::monitor"}).each do |node|
> > # make nagios checks node will be a object holding all
> > # the stored info about a node with hash like access
> > end
> >
> > My question is how to integrate this best, i need some utility
> classes, i need a db connection that will hopefully be shared between
> multiple catalog compiles in the same master process and between
> various invocations of the parser functions, utility classes etc. And
> I need configuration information - where to find the db.
> >
> > - Ideally this would be a plugin ala plugins in modules
> > - Config would be ideal in puppet.conf, but I dont believe plugins
> can access random data in there, especially ones puppet has in its
> code base i cant extend it?
> > - I need some var/pool that is accessible by the utility classes and
> that holds open a connection to a db
> >
> > Any hints?
> >
>
> - --
> Trevor Vaughan
> Vice President, Onyx Point, Inc.
> email: [email protected]
> phone: 410-541-ONYX (6699)
> pgp: 0x6C701E94
>
> - -- This account not approved for unencrypted sensitive information
> --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJMPuWHAAoJECNCGV1OLcypAEEIAIwCwA66yroEgQG5NmHlJxd8
> 8Tp+TtW3NkGLlWesN3utozjoyzXQ6YQFywoDh3d8UIDHaBi65GmT9GJ5470km2UG
> RCZWiECzzJ5qnhS6XQivxh6vdqr6q6y+Pgk9AuODxxi63aVXGHxDQrEE3jAh9HWv
> cpXUaGubqyLGuBzAVSSgzPObELkASeXUPD2gpd2Cess9kBBRqFnXEhjLsQ0B9aEy
> MDrjPanKgSylz05De1eWy0+4L6OW39HLJm4IhecawEwhaPiIry2ZYvN8cQPb1zug
> 00iBLZ0hcysjamivLaKCnZPt8D+/vrGBMpHSf5sRvQxLhkvtuQopE9EjZvjxHUs=
> =b8Gt
> -----END PGP SIGNATURE-----
--
R.I.Pienaar
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
