Hello All, We are investigating writing a custom puppet report that would be a web app to show a change log for each host. The issue we are running into stems from how we run puppet. We run a daily cronjob in noop and report mode and fix inconsistency''s either by hand or by puppet depending on the host. This should change some what in the future as our puppet environment matures but for now, this has worked ok. With that said, what we would like is a way to find out how puppet was run and pass that along to the report. This way we can select which runs we do want to report on by parsing that field. For these particular reports for example, we would only want to report when puppet was ran with pupdate against our production port (we have a port for developement/testing). We also could decipher false positives if puppet was ran with tags where a host could be consistent against some tag(s), but may not be consistent against all. Our thought was to add an option (call it --invocation) to pass in whatever you like and have :invocation passed along to the yaml report. Any thoughts on how to accomplish this would be appreciated. Thanks, -Steve
On Dec 20, 2007, at 11:44 AM, Steve Meier wrote:> Hello All, > > We are investigating writing a custom puppet report that would be a > web > app to show a change log for each host. The issue we are running into > stems from how we run puppet. We run a daily cronjob in noop and > report > mode and fix inconsistency''s either by hand or by puppet depending on > the host. This should change some what in the future as our puppet > environment matures but for now, this has worked ok. > > With that said, what we would like is a way to find out how puppet was > run and pass that along to the report. This way we can select which > runs > we do want to report on by parsing that field. For these particular > reports for example, we would only want to report when puppet was ran > with pupdate against our production port (we have a port for > developement/testing). We also could decipher false positives if > puppet > was ran with tags where a host could be consistent against some tag > (s), > but may not be consistent against all. > > > Our thought was to add an option (call it --invocation) to pass in > whatever you like and have :invocation passed along to the yaml > report. > Any thoughts on how to accomplish this would be appreciated.Hmm, I hadn''t thought of that. I think it probably makes more sense to allow definition of some kind of tags, which where then included in the report, but I''m not sure even how this would exactly work, I just think it would be more extensible. I''m certainly open to accepting this as a patch, but nothing like it is available currently. I''ll continue thinking about it, though, and there might be some simple way to do it that makes sense. Hmm. -- Wear the old coat and buy the new book. -- Austin Phelps --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 21 December 2007, Luke Kanies wrote:> On Dec 20, 2007, at 11:44 AM, Steve Meier wrote: > > Hello All, > > > > We are investigating writing a custom puppet report that would be a > > web > > app to show a change log for each host. The issue we are running into > > stems from how we run puppet. We run a daily cronjob in noop and > > report > > mode and fix inconsistency''s either by hand or by puppet depending on > > the host. This should change some what in the future as our puppet > > environment matures but for now, this has worked ok. > > > > With that said, what we would like is a way to find out how puppet was > > run and pass that along to the report. This way we can select which > > runs > > we do want to report on by parsing that field. For these particular > > reports for example, we would only want to report when puppet was ran > > with pupdate against our production port (we have a port for > > developement/testing). We also could decipher false positives if > > puppet > > was ran with tags where a host could be consistent against some tag > > (s), > > but may not be consistent against all. > > > > > > Our thought was to add an option (call it --invocation) to pass in > > whatever you like and have :invocation passed along to the yaml > > report. > > Any thoughts on how to accomplish this would be appreciated. > > Hmm, I hadn''t thought of that. I think it probably makes more sense > to allow definition of some kind of tags, which where then included > in the report, but I''m not sure even how this would exactly work, I > just think it would be more extensible. > > I''m certainly open to accepting this as a patch, but nothing like it > is available currently. I''ll continue thinking about it, though, and > there might be some simple way to do it that makes sense. Hmm.What about "just" including the used facts? That''s all client-side information in the compile anyways. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHbMju/Pp1N6Uzh0URAnE9AJ4s4MMH/lJYDfBob7eS4NpmrbgZuwCdHb8T ITB+R3ozXEvfTHunwdQh7E4=EjfV -----END PGP SIGNATURE-----
On Dec 22, 2007, at 2:21 AM, David Schmitt wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 21 December 2007, Luke Kanies wrote: >> On Dec 20, 2007, at 11:44 AM, Steve Meier wrote: >>> Hello All, >>> >>> We are investigating writing a custom puppet report that would be a >>> web >>> app to show a change log for each host. The issue we are running >>> into >>> stems from how we run puppet. We run a daily cronjob in noop and >>> report >>> mode and fix inconsistency''s either by hand or by puppet >>> depending on >>> the host. This should change some what in the future as our puppet >>> environment matures but for now, this has worked ok. >>> >>> With that said, what we would like is a way to find out how >>> puppet was >>> run and pass that along to the report. This way we can select which >>> runs >>> we do want to report on by parsing that field. For these particular >>> reports for example, we would only want to report when puppet was >>> ran >>> with pupdate against our production port (we have a port for >>> developement/testing). We also could decipher false positives if >>> puppet >>> was ran with tags where a host could be consistent against some tag >>> (s), >>> but may not be consistent against all. >>> >>> >>> Our thought was to add an option (call it --invocation) to pass in >>> whatever you like and have :invocation passed along to the yaml >>> report. >>> Any thoughts on how to accomplish this would be appreciated. >> >> Hmm, I hadn''t thought of that. I think it probably makes more sense >> to allow definition of some kind of tags, which where then included >> in the report, but I''m not sure even how this would exactly work, I >> just think it would be more extensible. >> >> I''m certainly open to accepting this as a patch, but nothing like it >> is available currently. I''ll continue thinking about it, though, and >> there might be some simple way to do it that makes sense. Hmm. > > What about "just" including the used facts? That''s all client-side > information > in the compile anyways.That sounds like a good idea, and would certainly be a simple solution. I do like the idea of having an invocation context, but I''m not sure how often it would really be used. Can anyone think of other uses for this? -- The remarkable thing about Shakespeare is that he really is very good, in spite of all the people who say he is very good. -- Robert Graves --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies schrieb:> On Dec 22, 2007, at 2:21 AM, David Schmitt wrote: >> What about "just" including the used facts? That''s all client-side >> information >> in the compile anyways. > > That sounds like a good idea, and would certainly be a simple > solution. I do like the idea of having an invocation context, but > I''m not sure how often it would really be used. > > Can anyone think of other uses for this?It might lead to a kind of inventory system, where facts detect H/W, networking, and what else and reports generate the component lists. It would also tie in with my notion of creating some special kind of "configuration variables" (that can be used for Template Class parameterisation) and creating a External Configuration Source alongside External Node Classification. Reporting the "invocation context" would then close the "loop" from administrator -> manifest -> compilation -> execution -> reporting -> administrator. Regards, DavidS
On Jan 2, 2008, at 5:08 AM, David Schmitt wrote:> Luke Kanies schrieb: >> On Dec 22, 2007, at 2:21 AM, David Schmitt wrote: >>> What about "just" including the used facts? That''s all client-side >>> information >>> in the compile anyways. >> >> That sounds like a good idea, and would certainly be a simple >> solution. I do like the idea of having an invocation context, but >> I''m not sure how often it would really be used. >> >> Can anyone think of other uses for this? > > It might lead to a kind of inventory system, where facts detect H/W, > networking, and what else and reports generate the component lists.The inventorying is already handled in other ways (currently using storeconfigs, and soon via more flexible mechanisms).> It would also tie in with my notion of creating some special kind of > "configuration variables" (that can be used for Template Class > parameterisation) and creating a External Configuration Source > alongside > External Node Classification. Reporting the "invocation context" would > then close the "loop" from administrator -> manifest -> compilation -> > execution -> reporting -> administrator.I''m not sure what you mean when you say "configuration variables" - can you elaborate? It''s true that an invocation context would provide more information to the admin, I''m just trying to understand if this is a fundamental concept that it makes sense to bake into the system, or just a useful thing that could easily be handled without adding something to the core. -- Talent hits a target no one else can hit; Genius hits a target no one else can see. -- Arthur Schopenhauer --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
We may take advantage of this too at some point - all the plumbing''s there to push out new facts and pull their results back - it''s just a case of pulling the results out of the DB and doing something with them. Currently we have the whole feedback loop David describes, but I too am not sure about what "invocation context" means. Do you mean the manifest + the ENC input + the facts? Cheers, Derek -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Luke Kanies Sent: 02 January 2008 20:13 To: Puppet User Discussion Subject: Re: [Puppet-users] Puppet Reports On Jan 2, 2008, at 5:08 AM, David Schmitt wrote:> Luke Kanies schrieb: >> On Dec 22, 2007, at 2:21 AM, David Schmitt wrote: >>> What about "just" including the used facts? That''s all client-side >>> information in the compile anyways. >> >> That sounds like a good idea, and would certainly be a simple >> solution. I do like the idea of having an invocation context, but >> I''m not sure how often it would really be used. >> >> Can anyone think of other uses for this? > > It might lead to a kind of inventory system, where facts detect H/W, > networking, and what else and reports generate the component lists.The inventorying is already handled in other ways (currently using storeconfigs, and soon via more flexible mechanisms).> It would also tie in with my notion of creating some special kind of > "configuration variables" (that can be used for Template Class > parameterisation) and creating a External Configuration Source > alongside External Node Classification. Reporting the "invocation > context" would then close the "loop" from administrator -> manifest ->> compilation -> execution -> reporting -> administrator.I''m not sure what you mean when you say "configuration variables" - can you elaborate? It''s true that an invocation context would provide more information to the admin, I''m just trying to understand if this is a fundamental concept that it makes sense to bake into the system, or just a useful thing that could easily be handled without adding something to the core. -- Talent hits a target no one else can hit; Genius hits a target no one else can see. -- Arthur Schopenhauer --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------
Luke Kanies schrieb:> On Jan 2, 2008, at 5:08 AM, David Schmitt wrote: > >> Luke Kanies schrieb: >>> On Dec 22, 2007, at 2:21 AM, David Schmitt wrote: >>>> What about "just" including the used facts? That''s all client-side >>>> information >>>> in the compile anyways. >>> That sounds like a good idea, and would certainly be a simple >>> solution. I do like the idea of having an invocation context, but >>> I''m not sure how often it would really be used. >>> >>> Can anyone think of other uses for this? >> It might lead to a kind of inventory system, where facts detect H/W, >> networking, and what else and reports generate the component lists. > > The inventorying is already handled in other ways (currently using > storeconfigs, and soon via more flexible mechanisms). > >> It would also tie in with my notion of creating some special kind of >> "configuration variables" (that can be used for Template Class >> parameterisation) and creating a External Configuration Source >> alongside >> External Node Classification. Reporting the "invocation context" would >> then close the "loop" from administrator -> manifest -> compilation -> >> execution -> reporting -> administrator. > > I''m not sure what you mean when you say "configuration variables" - > can you elaborate? > > It''s true that an invocation context would provide more information > to the admin, I''m just trying to understand if this is a fundamental > concept that it makes sense to bake into the system, or just a useful > thing that could easily be handled without adding something to the core.Something that came up in the discussion around automtated testing, was that it might be interesting to have the complete resource list as transferred to the client available for comparison. Here the "invocation context" might come handy too. But I currently don''t discern any "fundamental concepts". Regards, DavidS
On Jan 3, 2008, at 9:50 AM, David Schmitt wrote:> > Something that came up in the discussion around automtated testing, > was > that it might be interesting to have the complete resource list as > transferred to the client available for comparison. Here the > "invocation > context" might come handy too.Hmm, I hadn''t really thought about this, but we will need to version the configuration as stored on the server. We''re already storing the compiled resource list in the database (if storeconfigs is enabled), but it always just stores the most recent version, rather than keeping track of changes. It certainly makes sense to include the compile time/date in the report, and it probably makes sense to find a way to keep older versions of resource catalogs.> But I currently don''t discern any "fundamental concepts".Ok. -- Nature and nature''s laws lay hid in night, God said, "Let Newton be," and all was light. It did not last; the devil howling "Ho! Let Einstein be!" restored the status quo. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jan 3, 2008, at 2:53 AM, <Derek.Whayman@barclayscapital.com> <Derek.Whayman@barclayscapital.com > wrote:> We may take advantage of this too at some point - all the plumbing''s > there to push out new facts and pull their results back - it''s just a > case of pulling the results out of the DB and doing something with > them. > > Currently we have the whole feedback loop David describes, but I too > am > not sure about what "invocation context" means. Do you mean the > manifest + the ENC input + the facts?This term is one coined by the original poster; it would differentiate between, say, running in noop mode and not. -- It is better to sleep on things beforehand than lie awake about them afterward. -- Baltasar Gracian --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com