Greeting Puppeteers, ( I sent this from the wrong address so it may be a duplicate post after moderation ) I recently discovered puppet from the debian administration site and thought I might install it after BASHING my head against cfengine the last 3 times I tried to install it. I installed puppetmaster on my primary server and dropped puppet on a couple of xen virtuals. It worked straight up and was easy to get a base system working, I had a motd and issue.net distributed to all the machines within an hour. Good work Luke (and devs). So here''s me going, I wish you could store all the configs on the master (you can) , I wish it has ldap integration (it does) as I keep most of my structural configs in ldap. So after a few weeks messing about I thought I''d chime in and give praise :) and make some observations. So here goes. 1. I write most of my code in python ( but ruby looks pretty cool, although my eyes started bleeding after reading some tutorials :P ) but the ''puppet language'' seems to be nice and clean. 2. The store configs and export syntax and systems seem kind of weird to me, it would be cool if you declare virtual objects and get them back as an array to use instead of ( as in David''s munin example) where you have to create local files. eg: node- @@munin-node( IP , name) server- array = Munin-node <<||>> for i in array: do stuff or pass this array to a erb template. IMHO this would make it easier to apply the same configuration data in different ways to various classes. 3. Ldap integration, this is SO cool , I can just add classes to my nodes through my Ldap web interface, making node set up codeless for existing puppet classes. However I think that some minor changes would make the ldap interface much more powerful. 3.1 Inheritance: as ldap is a data tree it would be cool if the puppetClient class would inherit the classes defined in parent nodes ( be they OU''s or devices ). This would make the structure of the server classes easier to manage in large deployments. To this end I think the ldap schema would need a flag to disable/enable inheritance , so node classes could be isolated in the tree. 3.2 Ldap queries from the puppet class definitions: I keep dns , IP adresses and various other information in a Ldap database, I currently have a series of python scripts that use this information on the machines. However if puppet could be used to grab this information ( assigned IP adresses , routing , firewalls , etc ) more codeless node modifications could be done directly from the ldap server. Again , good work Luke (and devs) puppet looks like an excellent new (ish) way of managing larger networks with lots of machines in a sane way that does not have the fragility and cryptic failures and syntax that Cfengine suffers from. I am currently attempting to get some test machines running puppet at my work (.au ISP) as I think it will remove a large amount of grief that we have been suffering recently due to inconsistent configs. cheers. Simon Kirkby
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 04 June 2007, simon kirkby wrote:> 2. The store configs and export syntax and systems seem kind of weird > to me, it would be cool if you declare virtual objects and get them > back as an array to use instead of ( as in David''s munin example) > where you have to create local files. > > eg: > node- > @@munin-node( IP , name) > > server- > array = Munin-node <<||>> > for i in array: > do stuff > > or pass this array to a erb template. IMHO this would make it easier > to apply the same configuration data in different ways to various > classes.This sounds like a good idea, the trouble is that Puppet currently has only very weak array support and none for more complex types. As far as I have seen, puppet''s intention would be to implement the munin-node definition as a native type, which modifies munin.conf directly when collected. In the long term, this should probably be moved towards a inventory system, where I can just note that $HOST has $SERVICE on $PORT at $IP and everyone who needs this, can use templates or whatever to get information from there.> 3.2 Ldap queries from the puppet class definitions: I keep dns , IP > adresses and various other information in a Ldap database, I > currently have a series of python scripts that use this information > on the machines. However if puppet could be used to grab this > information ( assigned IP adresses , routing , firewalls , etc ) more > codeless node modifications could be done directly from the ldap server.You could fetch this information via custom functions. Take a look at https://reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions You could create something like {{{ # Fetch IP from LDAP $ip = from_ldap($attribute) }}} Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGZBlJ/Pp1N6Uzh0URAqThAJ4+Lv054fy92ROqAeV4MzoZnH0D+QCeIpEa sGdkL1Rgfeh9sf2T9S/zaNA=tAIy -----END PGP SIGNATURE-----
On Jun 3, 2007, at 8:31 PM, simon kirkby wrote:> [...] > It worked straight up and was easy to get a base system working, I > had a motd and issue.net distributed to all the machines within an > hour. Good work Luke (and devs).Great. [...]> So after a few weeks messing about I thought I''d chime in and give > praise :) and make some observations. So here goes.Thanks for the feedback; I appreciate it.> 1. I write most of my code in python ( but ruby looks pretty cool, > although my eyes started bleeding after reading some tutorials :P ) > but the ''puppet language'' seems to be nice and clean.Heh, the feeling''s mutual. :) I''m glad you like Puppet''s language, though.> 2. The store configs and export syntax and systems seem kind of weird > to me, it would be cool if you declare virtual objects and get them > back as an array to use instead of ( as in David''s munin example) > where you have to create local files. > > eg: > node- > @@munin-node( IP , name) > > server- > array = Munin-node <<||>> > for i in array: > do stuff > > or pass this array to a erb template. IMHO this would make it easier > to apply the same configuration data in different ways to various > classes.The problem is that Puppet has no support for the "do stuff" you''re talking about. That is, there are no operations you can perform on those resources, so there''s no point in being able to assign them to an array. What are you hoping to be able to do, anyway?> 3. Ldap integration, this is SO cool , I can just add classes to my > nodes through my Ldap web interface, making node set up codeless for > existing puppet classes. > > However I think that some minor changes would make the ldap interface > much more powerful. > > 3.1 Inheritance: as ldap is a data tree it would be cool if the > puppetClient class would inherit the classes defined in parent nodes > ( be they OU''s or devices ). This would make the structure of the > server classes easier to manage in large deployments. To this end I > think the ldap schema would need a flag to disable/enable > inheritance , so node classes could be isolated in the tree.I''m working on kinial[1], which will change how all of this works, including (I think) providing just about everything you''re asking for. The current ldap support is very limited because it was only meant to replace node declarations, but I expect we''ll be making an ldap back- end to kinial that will be much more ldap-ish.> 3.2 Ldap queries from the puppet class definitions: I keep dns , IP > adresses and various other information in a Ldap database, I > currently have a series of python scripts that use this information > on the machines. However if puppet could be used to grab this > information ( assigned IP adresses , routing , firewalls , etc ) more > codeless node modifications could be done directly from the ldap > server.As David mentioned, you can use server-side functions for this today, but one thing Kinial will definitely add is the ability to associate attributes with classes. You should have this soon, too.> Again , good work Luke (and devs) puppet looks like an excellent new > (ish) way of managing larger networks with lots of machines in a sane > way that does not have the fragility and cryptic failures and syntax > that Cfengine suffers from.Thanks! Please tell all of your friends. :) 1 - https://reductivelabs.com/trac/puppet/wiki/ ExternalNodeClassification -- Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for - in order to get to the job you need to pay for the clothes and the car, and the house you leave vacant all day so you can afford to live in it. -- Ellen DeGeneres --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:>> 2. The store configs and export syntax and systems seem kind of weird >> to me, it would be cool if you declare virtual objects and get them >> back as an array to use instead of ( as in David''s munin example) >> where you have to create local files. >> >> eg: >> node- >> @@munin-node( IP , name) >> >> server- >> array = Munin-node <<||>> >> for i in array: >> do stuff >> >> or pass this array to a erb template. IMHO this would make it easier >> to apply the same configuration data in different ways to various >> classes. > > The problem is that Puppet has no support for the "do stuff" you''re > talking about. That is, there are no operations you can perform on > those resources, so there''s no point in being able to assign them to > an array. > > What are you hoping to be able to do, anyway?Although this wasn''t my post originally, I''d like to chime in here about what I was hoping to be able to do with stored configs. I thought stored configs would allow me to do something on one node, and then use those results on another node. I was fighting stored configs last night thinking you could do this, but now I realize it is not possible. I wanted to generate a ssh public keypair on node1, store the id_dsa.pub, then on node2 collect the contents of that generated public key into a user''s .ssh/authorized_keys file. I see that is not possible now, and instead what I need to do is generate the keypair on the puppetmaster, then distribute that file to node2 and then add it to the authorized_keys file. I''ve been trying to minimize file { ... source => ...} calls as much as possible, but it seems like this is how I have to do it. It would be nice if I could take the contents of a file from one node (or the output from a command) and use that on another node, without having to do it all on the master. Micah
On Jun 4, 2007, at 7:28 PM, Micah Anderson wrote:> Although this wasn''t my post originally, I''d like to chime in here > about > what I was hoping to be able to do with stored configs. > > I thought stored configs would allow me to do something on one > node, and > then use those results on another node. I was fighting stored configs > last night thinking you could do this, but now I realize it is not > possible.Actually, it does exactly that, but I think you''re just thinking about it slightly differently.> I wanted to generate a ssh public keypair on node1, store the > id_dsa.pub, then on node2 collect the contents of that generated > public > key into a user''s .ssh/authorized_keys file. I see that is not > possible > now, and instead what I need to do is generate the keypair on the > puppetmaster, then distribute that file to node2 and then add it to > the > authorized_keys file. I''ve been trying to minimize file { ... > source => > ...} calls as much as possible, but it seems like this is how I > have to > do it.This is pretty straightforward, really, as long as you have a type that can manage authorized keys. The problem is that you need to export the key as the correct resource type. I believe you were exporting the key as a file, and then were hoping to manipulate it on node2; instead, export it as the correct resource on node1: @@authorized_key { $hostname: key => $sshdsakey } This presumes an ''authorized_key'' type exists. :) Then, on node2, collect all authorized keys: Authorized_key <<||>> So, you don''t really need to "do" anything with the key, not on node2, anyway. And if you think about it, this is generally what you''ll want anyway: The exporting node knows why it''s being exported and has the appropriate context for configuring it correctly. Note that you cannot currently (and possibly never will be able to) collect defined types, only native types. You can export defined types, but they get stored in the database as native types (e.g., files or execs), so you have to collect them as such. As a result, export/collect works far better with native types than defined types. -- Getting caught is the mother of invention. --Robert Byrne --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On Jun 4, 2007, at 7:28 PM, Micah Anderson wrote: >> I wanted to generate a ssh public keypair on node1, store the >> id_dsa.pub, then on node2 collect the contents of that generated >> public >> key into a user''s .ssh/authorized_keys file. I see that is not >> possible >> now, and instead what I need to do is generate the keypair on the >> puppetmaster, then distribute that file to node2 and then add it to >> the >> authorized_keys file. I''ve been trying to minimize file { ... >> source => >> ...} calls as much as possible, but it seems like this is how I >> have to >> do it. > > This is pretty straightforward, really, as long as you have a type > that can manage authorized keys. The problem is that you need to > export the key as the correct resource type.So I need to define a type to manage authorized keys and then export the key as that type.> @@authorized_key { $hostname: key => $sshdsakey } > > This presumes an ''authorized_key'' type exists. :) > > Then, on node2, collect all authorized keys: > > Authorized_key <<||>> > > So, you don''t really need to "do" anything with the key, not on > node2, anyway. And if you think about it, this is generally what > you''ll want anyway: The exporting node knows why it''s being exported > and has the appropriate context for configuring it correctly. > > Note that you cannot currently (and possibly never will be able to) > collect defined types, only native types. You can export defined > types, but they get stored in the database as native types (e.g., > files or execs), so you have to collect them as such. As a result, > export/collect works far better with native types than defined types.This is where I''m confused. You are telling me that the way to do this is by defining an authorized_key type, but then you are telling me that its not possible because you cannot collect defined types. Are you saying I need to create a native type for this to work? Or that I should define an authorized_key type and then collect as a File? Your example above seems to contradict this last option since you are showing a collection of the ''authorized_key'' type. Are you assuming the type is native in the example? Thanks for the clarifications, I really appreciate it. micah
On Jun 5, 2007, at 1:36 PM, Micah Anderson wrote:>> >> This is pretty straightforward, really, as long as you have a type >> that can manage authorized keys. The problem is that you need to >> export the key as the correct resource type. > > So I need to define a type to manage authorized keys and then > export the > key as that type.Yep, basically.> This is where I''m confused. You are telling me that the way to do this > is by defining an authorized_key type, but then you are telling me > that > its not possible because you cannot collect defined types. > > Are you saying I need to create a native type for this to work? Or > that > I should define an authorized_key type and then collect as a File? > Your > example above seems to contradict this last option since you are > showing > a collection of the ''authorized_key'' type. Are you assuming the > type is > native in the example?Yes, my example assumes a native type, and that''s what I have recommended for this all along. In fact, the existing sshkey could could trivially be used to build an authorized keys type. I have always maintained that native types are preferred to defined types. There are and will continue to be considerable benefits to using native types instead of defined types. I have spent a lot of time making it as easy as possible to build native types, and at the least it''s no harder than building defined types. Puppet will already automatically distribute these native types for you, and I''m working on making that even easier. It''s conceivable that export/collect could be used to collect defined types, too, but that would require some significant modification to the database, and I''m not sure it''s worth it. Additionally, unfortunately, export/collect is still experimental (although I''ve been working hard at changing that). I''m all for fixing the problems you''re seeing. I just don''t have the resources available, and no one is so concerned about them that they''re willing to pay to have them fixed, and I unfortunately have to make a large number of development choices based on what gets me food or possibly allows me to hire someone to help on the project, vs. what makes the community happiest. I don''t mean to whine; it''s just important to keep in mind that this is a large project maintained almost entirely by one person who until Puppet was not a professional developer. I''d love more help, and in the absence of it I''m actively trying to find more paying customers so I can pay people to work on Puppet, but in the meantime, there''s easily 10x as much work as I can do on the project. -- Measure with a micrometer. Mark with chalk. Cut with an axe. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On Jun 5, 2007, at 1:36 PM, Micah Anderson wrote:> Yes, my example assumes a native type, and that''s what I have > recommended for this all along. In fact, the existing sshkey could > could trivially be used to build an authorized keys type.Trivial if you know ruby... :) Guess its time to jump on the bandwagon and see how to do this.> I have always maintained that native types are preferred to defined > types. There are and will continue to be considerable benefits to > using native types instead of defined types. I have spent a lot of > time making it as easy as possible to build native types, and at the > least it''s no harder than building defined types. Puppet will > already automatically distribute these native types for you, and I''m > working on making that even easier.Assuming I learned enough ruby to write a native type for authorized_keys, where would I put it so that puppet will automatically distribute it?> It''s conceivable that export/collect could be used to collect defined > types, too, but that would require some significant modification to > the database, and I''m not sure it''s worth it. Additionally, > unfortunately, export/collect is still experimental (although I''ve > been working hard at changing that).If it works for native types, then I just need to overcome that hurdle to make it work how I want it, it sounds like a lot of work to make defined types work with export/collect, and getting a native type in place would be the simpler path.> I''m all for fixing the problems you''re seeing. I just don''t have the > resources available, and no one is so concerned about them that > they''re willing to pay to have them fixed, and I unfortunately have > to make a large number of development choices based on what gets me > food or possibly allows me to hire someone to help on the project, > vs. what makes the community happiest.I totally understand. I dont see this as a problem really, just a ''would be nice so i wouldn''t have to learn ruby''. I understand the resource contention issue and respect your work and need to prioritize features.> I don''t mean to whine; it''s just important to keep in mind that this > is a large project maintained almost entirely by one person who until > Puppet was not a professional developer. I''d love more help, and in > the absence of it I''m actively trying to find more paying customers > so I can pay people to work on Puppet, but in the meantime, there''s > easily 10x as much work as I can do on the project.Yep, I hope I didn''t come across as whining either, just wanted to pipe in and say that I thought this would work this way, and now that I realized it doesn''t it would be nice if it did, but I can live without it, especially if others aren''t really needing/wanting it and you''ve got your needs to take care of. If I had resources to contribute, I would, and because I don''t I am happy to spend the effort to figuring out how to do a native type (or work around it by generating on the master and distributing it). thanks for your hard work, micah
On Jun 5, 2007, at 4:53 PM, Micah Anderson wrote:> > Trivial if you know ruby... :) Guess its time to jump on the bandwagon > and see how to do this.Actually, not really. I believe that the gentoo and up2date providers were written by people with no Ruby experience, and this isn''t much more complicated than that.> Assuming I learned enough ruby to write a native type for > authorized_keys, where would I put it so that puppet will > automatically > distribute it?Create a ''plugins'' module in your fileserver.conf and stick them there. Then use --pluginsync on the client. Currently, only resource types are supported, but I''m working on making it generic enough so resource types, providers, and anything else can be synced. Note that when this change happens, it''ll break backward compatibility with the existing system. AFAICT, no one is using pluginsync right now, so this really shouldn''t be a problem.> If it works for native types, then I just need to overcome that hurdle > to make it work how I want it, it sounds like a lot of work to make > defined types work with export/collect, and getting a native type in > place would be the simpler path.Definitely. I could go into detail if you''re interested, and it''s work that is probably a reasonable task, but it''s pretty darn far down the priority list.> I totally understand. I dont see this as a problem really, just a > ''would > be nice so i wouldn''t have to learn ruby''. I understand the resource > contention issue and respect your work and need to prioritize > features.Well, this resource type seems to have a lot of people who are interested; just one of those interested parties needs to learn Ruby. Maybe you guys could put up a bounty for it or something.> Yep, I hope I didn''t come across as whining either, just wanted to > pipe > in and say that I thought this would work this way, and now that I > realized it doesn''t it would be nice if it did, but I can live without > it, especially if others aren''t really needing/wanting it and > you''ve got > your needs to take care of. If I had resources to contribute, I would, > and because I don''t I am happy to spend the effort to figuring out how > to do a native type (or work around it by generating on the master and > distributing it).I haven''t spent much time documenting export/collect because it has such severe performance problems and I don''t particularly want many people to use it, since I know it will just result in further support problems. Those problems are hopefully being solved by Allen Ballman right now, but they''re going to break backward compatibility (you''ll have to rebuild your database). Once this is working sufficiently, I''ll write up a better document on it (although I''d *love* it if someone else volunteered to create it). -- Yesterday upon the stair I met a man who wasn''t there. He wasn''t there again today -- I think he''s from the CIA. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On Jun 5, 2007, at 4:53 PM, Micah Anderson wrote: >> Trivial if you know ruby... :) Guess its time to jump on the bandwagon >> and see how to do this. > > Actually, not really. I believe that the gentoo and up2date > providers were written by people with no Ruby experience, and this > isn''t much more complicated than that.I took the bait, my attempt is here: http://pastie.caboo.se/68192 Everything seems fine, except that when I try to collect I get the error: err: Could not apply complete configuration: Parsed Providers must define a default target I was hoping that I could set the default_target to the :authorized_keys parameter that would be passed as such: @@authorized_key { "admin": authorized_keys => "/home/micah/.ssh/authorized_keys", key => "/var/www/.ssh/id_dsa.pub", } but it doesn''t look like I am passing the target parameter to the defaultto properly, and it can''t be set to ''nil'', I''m not exactly sure I know what I am doing in the parsed.rb, I was hoping it was going to be easy to just append to the file.> Create a ''plugins'' module in your fileserver.conf and stick them > there. Then use --pluginsync on the client.This worked great, thanks.> Well, this resource type seems to have a lot of people who are > interested; just one of those interested parties needs to learn > Ruby. Maybe you guys could put up a bounty for it or something.Well what I came up with is pretty basic so far, if I can get this to work, then maybe something more advanced could be in the works. micah
>>Hey luke, ----8<---->> or pass this array to a erb template. IMHO this would make it easier >> to apply the same configuration data in different ways to various >> classes. > > The problem is that Puppet has no support for the "do stuff" you''re > talking about. That is, there are no operations you can perform on > those resources, so there''s no point in being able to assign them to > an array. > > What are you hoping to be able to do, anyway?I was attempting to make a cleaner version of the munin client/server model, David''s is fine I just wanted to make it so the munin server did not have to be on the puppetmaster using export. So i created a simple munin type module Puppet newtype(:muninclient) do @doc = "Object to store munin clients in." newparam(:fqdn) do desc "Name of the munin client" isnamevar end newparam(:ip) do desc "ip of the munin client" isnamevar end end end then I created the virtual object in my munin-node client class munin-node { package{munin-node:ensure=>latest} @@muninclient{"munin_client_$fqdn": fqdn => $fqdn , ip => $ip} file { "/etc/munin/munin-node.conf": owner => root, group => root, mode => 411, source => "puppet://$server/files/default/etc/munin- node.conf" } service{ munin-node: ensure => running, subscribe => file[''/etc/munin/munin-node.conf''] } } This added all the data into the storeconfig database perfectly. Then I wanted this data in an array so I could then pass it to an .erb template from a munin-server class class munin-server{ package{munin:ensure=>latest} # Muninclient <<||>> ( i want this to as an array to insert into the template below ) file { "/etc/munin/munin.conf": owner => root, group => root, mode => 411, content => template(munin-server.erb) } service{ munin: ensure => running, subscribe => file[''/etc/munin/munin.conf''] } } munin-server.erb: # file built from puppet template dbdir /var/lib/munin htmldir /var/www/munin logdir /var/log/munin rundir /var/run/munin tmpldir /etc/munin/templates # a simple host tree <% fqdn.each do |host| -%> [<%= fqdn %>] address <%= ip %> use_node_name yes <% end -%> This could be used to plonk a munin-server as a class on any machine . From what you said I can''t get these (yet) as an array to pass to the munin-server.erb template. Access to the virtual objects in a more programmatic fashion would IMO be quite powerful. As the same bit of data could be used in different places. For example in a load balanced situation the same IP entry is used in the ha resources , ldirector config and a dummy interfaces on the vservers. Being able to access them easily within the puppet classes would be great.>8< ----> > I''m working on kinial[1], which will change how all of this works, > including (I think) providing just about everything you''re asking for. > > The current ldap support is very limited because it was only meant to > replace node declarations, but I expect we''ll be making an ldap back- > end to kinial that will be much more ldap-ish.I had a quick look at this looks like a good project , from how I understand it , it may solve the issues I have outlined above ( correct me if i''m wrong). Cheers. Simon Kirkby p.s I glad to see that this email list is nice and active ( a good sign ).
On Jun 6, 2007, at 12:49 AM, Micah Anderson wrote:> > I took the bait, my attempt is here: http://pastie.caboo.se/68192 > > Everything seems fine, except that when I try to collect I get the > error: > > err: Could not apply complete configuration: Parsed Providers must > define a default targetYou have two ways you can define the "target" in this type -- either the user (thus assuming that the file is always going to be ~user/.ssh/authorized_keys) or the path to the actual file. If you choose to make the target a user, I would set this to ''ENV ["USER"] || "root"''. If you make it the file, then I''d use the file for the user the process is running as. Hmm, actually... Use the file, since the user would be, um, a good bit harder, I think. You have to have a default target so that Puppet can read in existing resources, which is not really useful during the normal course of configuration but is critical for tools like ralsh.> I was hoping that I could set the default_target to > the :authorized_keys > parameter that would be passed as such: > > @@authorized_key { > "admin": > authorized_keys => "/home/micah/.ssh/authorized_keys", > key => "/var/www/.ssh/id_dsa.pub", > } > > but it doesn''t look like I am passing the target parameter to the > defaultto properly, and it can''t be set to ''nil'', I''m not exactly > sure I > know what I am doing in the parsed.rb, I was hoping it was going to be > easy to just append to the file.The default target for the provider is different than that for resource instances. In your provider definition, just set the default_target to the file path you want (I''d use "File.expand_path (''~/.ssh/authorized_keys'')"). In your type, you should use ''target'' instead of ''authorized_keys'', IMO, just for consistency (and it''ll be easier to make your type work with ParsedFile subclasses). You''ve got the ''defaultto'' code done correctly, but it needs to point to an actual file, so it''s the provider''s default target that''s broken.>> Create a ''plugins'' module in your fileserver.conf and stick them >> there. Then use --pluginsync on the client. > > This worked great, thanks. > >> Well, this resource type seems to have a lot of people who are >> interested; just one of those interested parties needs to learn >> Ruby. Maybe you guys could put up a bounty for it or something. > > Well what I came up with is pretty basic so far, if I can get this to > work, then maybe something more advanced could be in the works.You seem to have done a good job so far. If you catch me on IRC, I''ll be glad to help you get it finalized (or over email, of course). -- I worry that the person who thought up Muzak may be thinking up something else. --Lily Tomlin --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jun 6, 2007, at 8:35 AM, simon kirkby wrote:> [...] > This could be used to plonk a munin-server as a class on any > machine . From what you said I can''t get these (yet) as an array to > pass to the munin-server.erb template.It looks like the munin-client type doesn''t actually do anything; the idea here is that you would teach that type how to modify your munin server configuration, rather than using that template (or, possibly, use the template and then the clients to generate the configuration, although that would be... complicated). I''m of two minds here. The objects could certainly be available as such in these templates, but you''re suddenly using internal APIs and depending on stuff you really shouldn''t. It would be far better if you used the munin-client type to generate the correct configuration on the munin server, rather than using a template. This removes the need for an array, as far as I can tell.> Access to the virtual objects in a more programmatic fashion would > IMO be quite powerful. As the same bit of data could be used in > different places. For example in a load balanced situation the same > IP entry is used in the ha resources , ldirector config and a dummy > interfaces on the vservers.It''s just the same IP address that''s used, right, not the actual interface resource?> Being able to access them easily within the puppet classes would be > great.We''ve discussed this before, and no one (AFAI remember) has been able to come up with a clear use for it, and it significantly complicates the language. I think it makes sense to make it possible to get individual parameter values from resources (e.g., something like User [luke].uid), but it''s not terribly high on the priority list right now.> I had a quick look at this looks like a good project , from how I > understand it , it may solve the issues I have outlined above > ( correct me if i''m wrong).It won''t solve this problem at all -- it will just help solve the problems people are having with having node-specific attributes. -- To get back my youth I would do anything in the world, except take exercise, get up early, or be respectable. -- Oscar Wilde --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hey Luke,> I''m of two minds here. The objects could certainly be available as > such in these templates, but you''re suddenly using internal APIs and > depending on stuff you really shouldn''t. It would be far better if > you used the munin-client type to generate the correct configuration > on the munin server, rather than using a template. This removes the > need for an array, as far as I can tell.This would seem to me to be a round about way of creating a config file ( I may be thinking pythonicly about this). I am not conversant with the internals of puppet (for now) but I would have thought that a keeping a data base of store configs on the puppetmaster would mean that there would be straight forward way of getting this information out so config files / classes could be constructed from them. I see in another thread that you are loath to support storeconfig/ export code for now as the is still in flux and retrofitting recipes onto new and changing code can be a royal PITA. Still early days and a robust discussion is sure to iron out the bugs/features. Can you point me towards the ''storeconfig/export'' code as I would like to have a look ( assuming my eyes don''t bleed too much :P ) cheers. Simon
On Jun 7, 2007, at 8:08 AM, simon kirkby wrote:> > This would seem to me to be a round about way of creating a config > file ( I may be thinking pythonicly about this).It depends on how you look at it. It''s a round-about way of creating the files, but a direct way of specifying the configuration data. Also, you get much better logging when you use this method (e.g., you get notified that a given field of a given host has changed, rather than just "this file changed").> I am not conversant with the internals of puppet (for now) but I > would have thought that a keeping a data base of store configs on the > puppetmaster would mean that there would be straight forward way of > getting this information out so config files / classes could be > constructed from them.The purpose of the database is to allow one host to send configuration data to another host (e.g., an ldap server configurating the monitoring server), and for configuration inspection (eventually).> I see in another thread that you are loath to support storeconfig/ > export code for now as the is still in flux and retrofitting recipes > onto new and changing code can be a royal PITA. Still early days and > a robust discussion is sure to iron out the bugs/features. > > Can you point me towards the ''storeconfig/export'' code as I would > like to have a look ( assuming my eyes don''t bleed too much :P )It''s currently all in lib/puppet/parser/collector.rb. The problem is with the Rails/ActiveRecord integration, not with that code, and Allen Ballman is hopefully nearly done fixing that integration. -- Wear the old coat and buy the new book. -- Austin Phelps --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> > The problem is with the Rails/ActiveRecord integration, not with that > code, and Allen Ballman is hopefully nearly done fixing that > integration. > >i cannot wait for that so i can eventualy use the allmyghty puppetmaster to setup automaticaly my backup and monitoring servers :) Allen i am with you !! :) -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
simon kirkby wrote:> I was attempting to make a cleaner version of the munin client/server > model, David''s is fine I just wanted to make it so the munin server > did not have to be on the puppetmaster using export.For the record, David''s munin setup does _not_ require that the munin server is on the puppetmaster itself. I''m using it and the munin server is not on the puppetmaster server.