Hi,
We have got puppet set up and running at our main office with no
issues.
We are using an external node classifier instead of directly creating
node definition files.
We would like to manage our remote offices using puppet also. A little
about our set up. From our main site we have VPN links out to a remote
site. each site is generally identical with the same number of servers
and roughly the same services running on each server. Essentially
the only differences at each remote site the subnet and related IP
addresses.
Since we are using an external node classifier we do not explicitly
have node definition so we can not inherit a class and override a
default value.
Is there a way to do this using node classifiers?
An example will probably show this better
Site1:
+ location UK
+ subnet 192.168.1.0/24
+ gateway 192.168.1.254 (acts also as nameserver and local
dns etc
for all servers at site
1, for example ntp will
use the closest time
source geographically)
+ sever1 ip - 192.168.1.1 gateway of 192.168.1.254
+ sever2 ip - 192.168.1.2 gateway of 192.168.1.254
Site 2:
+ location US
+ subnet 192.168.2.0/24
+ gateway 192.168.2.254 (acts also as nameserver and local
dns etc
for all servers at site
2, for example ntp will
use the closest time
source geographically)
+ sever1 ip - 192.168.2.1 gateway of 192.168.2.254
+ sever2 ip - 192.168.2.2 gateway of 192.168.2.254
As you can see most details are identical between sites except for a
few
network and geographical differences.
Has there been any consensus within the community on the best way to
manage situations like this?
--
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nat wrote:> Hi, > > We have got puppet set up and running at our main office with no > issues. > We are using an external node classifier instead of directly creating > node definition files. > > We would like to manage our remote offices using puppet also. A little > about our set up. From our main site we have VPN links out to a remote > site. each site is generally identical with the same number of servers > and roughly the same services running on each server. Essentially > the only differences at each remote site the subnet and related IP > addresses. > > Since we are using an external node classifier we do not explicitly > have node definition so we can not inherit a class and override a > default value. > Is there a way to do this using node classifiers? > > > An example will probably show this better > > Site1: > + location UK > + subnet 192.168.1.0/24 > + gateway 192.168.1.254 (acts also as nameserver and local > dns etc > for all servers at site > 1, for example ntp will > use the closest time > source geographically) > + sever1 ip - 192.168.1.1 gateway of 192.168.1.254 > + sever2 ip - 192.168.1.2 gateway of 192.168.1.254 > Site 2: > + location US > + subnet 192.168.2.0/24 > + gateway 192.168.2.254 (acts also as nameserver and local > dns etc > for all servers at site > 2, for example ntp will > use the closest time > source geographically) > + sever1 ip - 192.168.2.1 gateway of 192.168.2.254 > + sever2 ip - 192.168.2.2 gateway of 192.168.2.254 > > As you can see most details are identical between sites except for a > few > network and geographical differences. > > Has there been any consensus within the community on the best way to > manage situations like this? >Well, I think a large portion of users have discovered that RI Pienaar''s (Volcane on IRC) extlookup.rb add on is good for this sort of stuff. It''s basically a function that looks up data in a csv file. So say your locations are domains like us.yourcompany.com. You can have a file called us.yourcompany.com.csv in a directory under /etc/puppet, or you set a location some other way you can have a us.csv file in the directory. I call my external lookup directory ''extdata'', and it looks up in the order of something like fqdn, domain, location, common (if it fails to find one csv, it moves on to the next). Then inside your manifest you set variables like: $something = extlookup("something") It''s really got so many uses I encourage you to use it. It was the only way I could solve a lot of puppet problems I ran into. Here is the page: http://www.devco.net/?s=extlookup - -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L''ennui est contre-révolutionnaire -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkt05q4ACgkQRkBieEaRmuZWDgCfdk89Fk1eyC9ichJIbjN9Jldj z1wAn0lUYhjxeqAinqjSZuS7MqkG+hnp =SZh3 -----END PGP SIGNATURE----- -- 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 Thu, Feb 11, 2010 at 7:20 PM, Nat <qwerty.nat@gmail.com> wrote:> Hi, > > We have got puppet set up and running at our main office with no > issues. > We are using an external node classifier instead of directly creating > node definition files. > > We would like to manage our remote offices using puppet also. A little > about our set up. From our main site we have VPN links out to a remote > site. each site is generally identical with the same number of servers > and roughly the same services running on each server. Essentially > the only differences at each remote site the subnet and related IP > addresses. > > Since we are using an external node classifier we do not explicitly > have node definition so we can not inherit a class and override a > default value. > Is there a way to do this using node classifiers? > > > An example will probably show this better > > Site1: > + location UK > + subnet 192.168.1.0/24 > + gateway 192.168.1.254 (acts also as nameserver and local > dns etc > for all servers at site > 1, for example ntp will > use the closest time > source geographically) > + sever1 ip - 192.168.1.1 gateway of 192.168.1.254 > + sever2 ip - 192.168.1.2 gateway of 192.168.1.254 > Site 2: > + location US > + subnet 192.168.2.0/24 > + gateway 192.168.2.254 (acts also as nameserver and local > dns etc > for all servers at site > 2, for example ntp will > use the closest time > source geographically) > + sever1 ip - 192.168.2.1 gateway of 192.168.2.254 > + sever2 ip - 192.168.2.2 gateway of 192.168.2.254 > > As you can see most details are identical between sites except for a > few > network and geographical differences. > > Has there been any consensus within the community on the best way to > manage situations like this? >I was talking with Eric yesterday about his external nodes regex classifier: http://github.com/reductivelabs/puppet/tree/master/ext/regexp_nodes/ This might be a start to some sort of evolved smart node idea (that we could stick in Dashboard and also build a CLI tool to) that could support the concept of variable inheritance. So not just define what machines are webservers (rather than what webservers are what machine) but use similar regexen (or another system of groups) to classify what machines live in what areas -- and blend the two groups together. Dan Bode mentions he sees several logical groups here -- there''s what type of a machine you have, whether it''s a stage/prod machine, and what location (datacenter) it is in (i.e. what is the machine''s geographic location). Some variables may come from one or more of those sources, and they can have some basic defaults. (This is somewhat similar to Cobbler''s "blender" inheritance for groups of things... allowing extension of arrays and adding keys to hashes, or overriding of scalars, as we evaluate the group orders. The location groups and the classification groups would not need to be chained (i..e one a parent of another) but we''d want to support the idea of inherited subgroups (acme-datacenter is a subset of us-datacenters is a subset of datacenters). Apologies if I''m being confusing :) There''s obviously a lot to do here, but I can see the need for a intelligent external nodes classifier that understands those kinds of ideas that can really model a multi-site environment as a first class concept. --Michael -- 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 Fri, Feb 12, 2010 at 11:41 AM, Michael DeHaan <michael@reductivelabs.com> wrote:> On Thu, Feb 11, 2010 at 7:20 PM, Nat <qwerty.nat@gmail.com> wrote: >> Hi, >> >> We have got puppet set up and running at our main office with no >> issues. >> We are using an external node classifier instead of directly creating >> node definition files. >> >> We would like to manage our remote offices using puppet also. A little >> about our set up. From our main site we have VPN links out to a remote >> site. each site is generally identical with the same number of servers >> and roughly the same services running on each server. Essentially >> the only differences at each remote site the subnet and related IP >> addresses. >> >> Since we are using an external node classifier we do not explicitly >> have node definition so we can not inherit a class and override a >> default value. >> Is there a way to do this using node classifiers? >> >> >> An example will probably show this better >> >> Site1: >> + location UK >> + subnet 192.168.1.0/24 >> + gateway 192.168.1.254 (acts also as nameserver and local >> dns etc >> for all servers at site >> 1, for example ntp will >> use the closest time >> source geographically) >> + sever1 ip - 192.168.1.1 gateway of 192.168.1.254 >> + sever2 ip - 192.168.1.2 gateway of 192.168.1.254 >> Site 2: >> + location US >> + subnet 192.168.2.0/24 >> + gateway 192.168.2.254 (acts also as nameserver and local >> dns etc >> for all servers at site >> 2, for example ntp will >> use the closest time >> source geographically) >> + sever1 ip - 192.168.2.1 gateway of 192.168.2.254 >> + sever2 ip - 192.168.2.2 gateway of 192.168.2.254 >> >> As you can see most details are identical between sites except for a >> few >> network and geographical differences. >> >> Has there been any consensus within the community on the best way to >> manage situations like this? >> > > I was talking with Eric yesterday about his external nodes regex classifier: > > http://github.com/reductivelabs/puppet/tree/master/ext/regexp_nodes/I see this classifier uses "hostname" to refer to what strictly speaking is the certname...> > This might be a start to some sort of evolved smart node idea (that we > could stick in Dashboard and also build a CLI tool to) that could > support the concept of variable inheritance. So not just define what > machines are webservers (rather than what webservers are what machine) > but use similar regexen (or another system of groups) to classify what > machines live in what areas -- and blend the two groups together.Aren''t we going to need more info than just the certname for external nodes to be able to really be able to functionally classify them? I realize this is a bit of a hobby horse for me as we don''t use hostnames for the certname... :) but even if you''re using hostnames as certnames do you really want to have to encode all this info into the hostnames?> > Dan Bode mentions he sees several logical groups here -- there''s what > type of a machine you have, whether it''s a stage/prod machine, and > what location (datacenter) it is in (i.e. what is the machine''s > geographic location). Some variables may come from one or more of > those sources, and they can have some basic defaults. (This is > somewhat similar to Cobbler''s "blender" inheritance for groups of > things... allowing extension of arrays and adding keys to hashes, or > overriding of scalars, as we evaluate the group orders. The > location groups and the classification groups would not need to be > chained (i..e one a parent of another) but we''d want to support the > idea of inherited subgroups (acme-datacenter is a subset of > us-datacenters is a subset of datacenters). Apologies if I''m being > confusing :) > > There''s obviously a lot to do here, but I can see the need for a > intelligent external nodes classifier that understands those kinds of > ideas that can really model a multi-site environment as a first class > concept. > > --Michael > > -- > 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. > >-- nigel -- 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.
Michael DeHaan wrote:> On Thu, Feb 11, 2010 at 7:20 PM, Nat <qwerty.nat@gmail.com> wrote: >> Hi, >> >> We have got puppet set up and running at our main office with no >> issues. >> We are using an external node classifier instead of directly creating >> node definition files. >> >> We would like to manage our remote offices using puppet also. A little >> about our set up. From our main site we have VPN links out to a remote >> site. each site is generally identical with the same number of servers >> and roughly the same services running on each server. Essentially >> the only differences at each remote site the subnet and related IP >> addresses. >> >> Since we are using an external node classifier we do not explicitly >> have node definition so we can not inherit a class and override a >> default value. >> Is there a way to do this using node classifiers? >> >> >> An example will probably show this better >> >> Site1: >> + location UK >> + subnet 192.168.1.0/24 >> + gateway 192.168.1.254 (acts also as nameserver and local >> dns etc >> for all servers at site >> 1, for example ntp will >> use the closest time >> source geographically) >> + sever1 ip - 192.168.1.1 gateway of 192.168.1.254 >> + sever2 ip - 192.168.1.2 gateway of 192.168.1.254 >> Site 2: >> + location US >> + subnet 192.168.2.0/24 >> + gateway 192.168.2.254 (acts also as nameserver and local >> dns etc >> for all servers at site >> 2, for example ntp will >> use the closest time >> source geographically) >> + sever1 ip - 192.168.2.1 gateway of 192.168.2.254 >> + sever2 ip - 192.168.2.2 gateway of 192.168.2.254 >> >> As you can see most details are identical between sites except for a >> few >> network and geographical differences. >> >> Has there been any consensus within the community on the best way to >> manage situations like this? >> > > I was talking with Eric yesterday about his external nodes regex classifier: > > http://github.com/reductivelabs/puppet/tree/master/ext/regexp_nodes/ > > This might be a start to some sort of evolved smart node idea (that we > could stick in Dashboard and also build a CLI tool to) that could > support the concept of variable inheritance. So not just define what > machines are webservers (rather than what webservers are what machine) > but use similar regexen (or another system of groups) to classify what > machines live in what areas -- and blend the two groups together. > > Dan Bode mentions he sees several logical groups here -- there''s what > type of a machine you have, whether it''s a stage/prod machine, and > what location (datacenter) it is in (i.e. what is the machine''s > geographic location). Some variables may come from one or more of > those sources, and they can have some basic defaults. (This is > somewhat similar to Cobbler''s "blender" inheritance for groups of > things... allowing extension of arrays and adding keys to hashes, or > overriding of scalars, as we evaluate the group orders. The > location groups and the classification groups would not need to be > chained (i..e one a parent of another) but we''d want to support the > idea of inherited subgroups (acme-datacenter is a subset of > us-datacenters is a subset of datacenters). Apologies if I''m being > confusing :) > > There''s obviously a lot to do here, but I can see the need for a > intelligent external nodes classifier that understands those kinds of > ideas that can really model a multi-site environment as a first class > concept. > > --Michael >I don''t want to sound a fanboy or one of Volcane''s minions, but I think his idea is spot on for this kind of thing. If it had LDAP/other DB support it would be even more ridiculously awesome. At the base of this problem, your base solution is you just need a function that can look up arbitrary data. Hostname can come into play, but with extlookup you can choose an order of precedence (IE overriding: hostname.csv trumps domain.csv or vice versa and it''s all configurable). I use CSV files cause I am lazy, it is easy, and my environment is small. Someone at $FORTUNE500 could use LDAP if the tool was extended slightly. As I recall however, extlookup.rb is not included in mainline puppet because Luke disagrees with the implementation I think. Could be wrong here. Best to ask him. I deploy it as part of my deploy:cold cap task for new masters. My uses for extlookup: * combined with ERB to create iptables firewalls * in puppetdoc, $location shows you where it lives since you can set it in the csv files (huge, huge win) * override DNS stupidity, which a lot people have. Or to simple force hostnames in case a master is having performance issues and you need to re route some clients. You just change the value in the csv. * Current list of admins to realize even can be done in the csv. The point is, a tool like this should be in puppet, extlookup.rb right now kicks a lot of ass. RL can do what they want obviously, but they should look at this tool. Mike, have you checked this tool out? You should if you haven''t had the chance yet. It''s just a custom parser function, two lines in your site.pp and a master restart. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L''ennui est contre-révolutionnaire -- 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.
hello,> > This might be a start to some sort of evolved smart node idea (tha we > > could stick in Dashboard and also build a CLI tool to) that could > > support the concept of variable inheritance. So not just define what > > machines are webservers (rather than what webservers are what machine) > > but use similar regexen (or another system of groups) to classify what > > machines live in what areas -- and blend the two groups together. > > > > Dan Bode mentions he sees several logical groups here -- there''s what > > type of a machine you have, whether it''s a stage/prod machine, and > > what location (datacenter) it is in (i.e. what is the machine''s > > geographic location). Some variables may come from one or more of > > those sources, and they can have some basic defaults. (This is > > somewhat similar to Cobbler''s "blender" inheritance for groups of > > things... allowing extension of arrays and adding keys to hashes, or > > overriding of scalars, as we evaluate the group orders. The > > location groups and the classification groups would not need to be > > chained (i..e one a parent of another) but we''d want to support the > > idea of inherited subgroups (acme-datacenter is a subset of > > us-datacenters is a subset of datacenters). Apologies if I''m being > > confusing :)Did you look at extlookup? Cos thats what it does.> I don''t want to sound a fanboy or one of Volcane''s minions, but I think > his idea is spot on for this kind of thing. If it had LDAP/other DB > support it would be even more ridiculously awesome. At the base of > this problem, your base solution is you just need a function that can look > up arbitrary data. Hostname can come into play, but with extlookup you > can choose an order of precedence (IE overriding: hostname.csv trumps > domain.csv or vice versa and it''s all configurable). I use CSV files > cause I am lazy, it is easy, and my environment is small. Someone at > $FORTUNE500 could use LDAP if the tool was extended slightly.Julian Simpson is working on making the backends pluggable so we should have something soon. Foreman already has integration on its side for extlookup (it''s in trunk or something) as soon as Julian and I finish making the backend pluggable it will be able to integrate easily into foreman.> As I recall however, extlookup.rb is not included in mainline puppet > because Luke disagrees with the implementation I think. Could be > wrong here. Best to ask him. I deploy it as part of my deploy:cold cap task > for new masters.Luke has said if we make it pluggable and make tests he''d be open to including it in base so we''re working on that.> The point is, a tool like this should be in puppet, extlookup.rb > right now kicks a lot of ass. RL can do what they want obviously, but they > should look at this tool.there''s a ticket for something like this already, I''ve highlighted all what extlookup does so hopefully we''ll get there one way or the other! -- 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.
> Did you look at extlookup? Cos thats what it does.Not enough apparently ... I thought it did something completely different. Sweet! We need to merge more of the ideas in ext with core, for sure. Seems like it would be easy to tweak to do multiple data sources (like DBs/NoSQL). --Michael -- 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 Fri, Feb 12, 2010 at 9:41 PM, Michael DeHaan <michael@reductivelabs.com>wrote:> > This might be a start to some sort of evolved smart node idea (that we > could stick in Dashboard and also build a CLI tool to) that could > support the concept of variable inheritance. So not just define what > machines are webservers (rather than what webservers are what machine) > but use similar regexen (or another system of groups) to classify what > machines live in what areas -- and blend the two groups together. >I hate to bring it up again, but this kind of functionality is already in Foreman since 0.1..... cheers, Ohad -- 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.
> > Julian Simpson is working on making the backends pluggable so we should > have > something soon. > > Foreman already has integration on its side for extlookup (it''s in trunk or > something) as soon as Julian and I finish making the backend pluggable it > will be able to integrate easily into foreman. >It should be very simple to add foreman support now. There''s an ExtLookup class that has a backend. There''s already the CSV backend that R.I. originally wrote, and it''s pretty straightforward to see how you could pass it another backend.> > > As I recall however, extlookup.rb is not included in mainline puppet > > because Luke disagrees with the implementation I think. Could be > > wrong here. Best to ask him. I deploy it as part of my deploy:cold cap > task > > for new masters. > > Luke has said if we make it pluggable and make tests he''d be open to > including it in base so we''re working on that. >It has tests. In fact it has reasonable test coverage. I''m just trying to pull logic out of the function that it originally shipped with and into the main ExtLookup class. I should probably reach out to the puppet-dev list so I can get some feedback. http://code.google.com/p/extlookup/ J. -- Julian Simpson Software Build and Deployment http://www.build-doctor.com http://twitter.com/builddoctor -- 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 Sun, Feb 14, 2010 at 10:57 PM, Julian Simpson <simpsonjulian@gmail.com>wrote:> > Foreman already has integration on its side for extlookup (it''s in trunk or >> something) as soon as Julian and I finish making the backend pluggable it >> will be able to integrate easily into foreman. >> > > It should be very simple to add foreman support now. There''s an ExtLookup > class that has a backend. There''s already the CSV backend that R.I. > originally wrote, and it''s pretty straightforward to see how you could pass > it another backend. >Thats great, please let me know when, and I''ll merge the code into the main branch and the official release. cheers, Ohad -- 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 the advice so far.
We have looked at the following ideas for our implementation
1. an external node classifier with variables passed in the
parameters
section of the YAML to nodes.
2. extlookup
3. forman and dashboard - there are not really feasible at the moment
due to our current set up with our external node data store
My question is what is the conceptual difference between options
1 and 2? is there differences between scope of variables defined
either way?
--
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.
hello, ----- "Nat" <qwerty.nat@gmail.com> wrote:> 1. an external node classifier with variables passed in the > parameters section of the YAML to nodes. > 2. extlookup> My question is what is the conceptual difference between options > 1 and 2? is there differences between scope of variables defined > either way?with the node tool your essentially defining a whole long list of global variables and they''re available in all classes. You should know upfront all the variables you need to define and (I think) you dont have a way to access the facts of the nodes when you''re doing the node tool output which makes it hard to make decisions based on that. It also means your node tool need a lot of knowledge/logic to set all these variables and defaults etc. I recall something about facts being passed on STDIN but dont see it in the docs so maybe i am wrong there and node tools do get access to fact. with a node tool if you needed to set ntp servers based on country, or facts or something you basically still need to write a lot of case statements - the difference is you''re just moving this logic driven decision making from puppet manifests to the external node tool - adding a new site generally either require code changes or a lot of work in modeling the data. Foreman does this nicely at the moment with its database structure but you are restricted to the kinds of data it allows you to model, to model other relationships would require code changes. (well, till extlookup supports talking to it anyway then the two would make quite a good combination and any effort you now put into using extlookup will pay off double then) With extlookup you set the data requirements where used - in the class - and where you are looking up the value you can also set a default, with access to facts: given the class: class ntp::config { file{"/etc/ntp.conf": template("ntp.conf.erb")} } looking at this you dont know what''s going on, what does the ERB need, what vars should your node tool pass? it takes a fair bit of digging to know whats going on - say you''re sharing your module with a mate who has his own node tool. now consider: class ntp::config { $ntpserver = extlookup("ntpserver", "${country}.pool.ntp.org") file{"/etc/ntp.conf": template("ntp.conf.erb")} } you look at this and you know what data you can provide - and you already know it degrades cleanly if you dont set anything sharing this kind of code is much easier than the other one. Now your needs change and maybe today you need lookup ability for fqdn, data center, country tomorrow you might also need one based on customer or even something weird like time of day. With a node tool as i said you''d need to go code this in, with extlookup you just configure it in one line of config. The upcoming puppet feature where you have parameters per class can help with the discovery phase of what data to pass but i am not sure how/if that integrates with external nodes, didn''t see that mentioned in the release notes -- 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.
Hi, On Sun, Feb 14, 2010 at 3:31 PM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > ----- "Nat" <qwerty.nat@gmail.com> wrote: > > > 1. an external node classifier with variables passed in the > > parameters section of the YAML to nodes. > > 2. extlookup > > > My question is what is the conceptual difference between options > > 1 and 2? is there differences between scope of variables defined > > either way? >with regards to scope, its possible that extlookup is more reliable since it determines the value for the config inline, thus removing any chance that a global variable assiged from the classifier would be overridden from an enclosing scope. This scoping issue for the external node classifier can be solved by namespacing the params, I used my_ for this (although this wouldnt work well when classes will have constructors in Rwolf) In my view, they are functionally equivalent an even similar. They both rely on code that looks up params from an external source. The external node classifier does it before the puppet run then applies the params at top scope, where extlookup determines the information in your puppet code.> with the node tool your essentially defining a whole long list of global > variables and they''re available in all classes. You should know upfront all > the variables you need to define and (I think) you dont have a way to access > the facts of the nodes when you''re doing the node tool output which makes it > hard to make decisions based on that. It also means your node tool need a > lot of knowledge/logic to set all these variables and defaults etc. I > recall something about facts being passed on STDIN but dont see it in the > docs so maybe i am wrong there and node tools do get access to fact. >There are ways to access facts from an external node classifier. Namely, by parsing the $varlib/nodes/facts/HOSTNAME.yaml file (which is guarenteed to be created before your external node classifier is run) I agree this is not the cleanest way to do this, and have even opened a ticket several months ago http://projects.reductivelabs.com/issues/2356 (before I worked at RL:)> > with a node tool if you needed to set ntp servers based on country, or > facts or something you basically still need to write a lot of case > statements - the difference is you''re just moving this logic driven decision > making from puppet manifests to the external node tool - adding a new site > generally either require code changes or a lot of work in modeling the data. >I see this a little differently: the node tool needs a way to assign which groups of params should be assigned to which nodes. The groups of params should support inheritence. default / \ site 1 site 2 / subnet 1 / application all of the conditional logic for assigning groups of params to nodes should only be written once. After that, changes should just involve configuration. ... Foreman does this nicely at the moment with its database structure but you> are restricted to the kinds of data it allows you to model, to model other > relationships would require code changes. (well, till extlookup supports > talking to it anyway then the two would make quite a good combination and > any effort you now put into using extlookup will pay off double then) > > > With extlookup you set the data requirements where used - in the class - > and where you are looking up the value you can also set a default, with > access to facts: >given the class:> > class ntp::config { > file{"/etc/ntp.conf": template("ntp.conf.erb")} > } > > looking at this you dont know what''s going on, what does the ERB need, what > vars should your node tool pass? it takes a fair bit of digging to know > whats going on - say you''re sharing your module with a mate who has his own > node tool. > > now consider: > > class ntp::config { > $ntpserver = extlookup("ntpserver", "${country}.pool.ntp.org") > > file{"/etc/ntp.conf": template("ntp.conf.erb")} > } > > you look at this and you know what data you can provide - and you already > know it degrades cleanly if you dont set anything sharing this kind of code > is much easier than the other one. > > Now your needs change and maybe today you need lookup ability for fqdn, > data center, country tomorrow you might also need one based on customer or > even something weird like time of day. With a node tool as i said you''d > need to go code this in,I disagree with this assumption. I think that with a node tool (ifs its written correctly), you would just have to choose the groups of params that you want to use. If your requirements change, then just reassign a different group of parameters (or change 1 of the param values for a group).> with extlookup you just configure it in one line of config. >Wouldnt there be cases where you have to change every line of puppet code that uses the extlookup tool if the properties that determine the lookup change? The upcoming puppet feature where you have parameters per class can help> with the discovery phase of what data to pass but i am not sure how/if that > integrates with external nodes, didn''t see that mentioned in the release > notes > >yes, there should be some way to tie with to the external classifier. Need more info... begin rant I have this idea that the ideal solution is a combination of using both an external node classifier as well as an extlookup tool. The classifier handles the assignment of gorups of params based on inheritance. Most param information is determined by some external feature of a node. What site am I at? What DC? What subnet? What is my role? These params should be assigned by an external node classifier. This allows us to control how these values are assigned outside of the scope of our puppet code. Some param information is always determined by some fact about our node (think platform). These types of params should be set with an extlookup tool (or something similar). This extlookup tool should just be accessing config from some kind of per module config fille. Think about how strings vary between platform, arch, fact an an internationalization problem. file{''ssh'': name => extlookup(ssh-name, $operatingsystem) } end rant --> 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- 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.
hello,> with regards to scope, its possible that extlookup is more reliable > since it determines the value for the config inline, thus removing any > chance that a global variable assiged from the classifier would be > overridden from an enclosing scope. This scoping issue for the > external node classifier can be solved by namespacing the params, I > used my_ for this (although this wouldnt work well when classes will > have constructors in Rwolf)sure, but it just shows why global variables have been abandoned by all but the most sucky devs and languages, puppet has some way to go to make this easy for us to do the right thing :)> In my view, they are functionally equivalent an even similar. They > both rely on code that looks up params from an external source. The > external node classifier does it before the puppet run then applies > the params at top scope, where extlookup determines the information in > your puppet code.for me the simplicity of how extlookup does it appeals, 100 lines to have something that achieves this compared to super complex node classifiers.> There are ways to access facts from an external node classifier. > Namely, by parsing the $varlib/nodes/facts/HOSTNAME.yaml file (which > is guarenteed to be created before your external node classifier is > run) I agree this is not the cleanest way to do this, and have even > opened a ticket several months ago > http://projects.reductivelabs.com/issues/2356 (before I worked at RL:)yeah, hacky though, I wouldnt suggest that a node classifier being on the same box as the master is a good idea.> I see this a little differently: the node tool needs a way to assign > which groups of params should be assigned to which nodes. The groups > of params should support inheritence. > > default > / \ > site 1 site 2 > / > subnet 1 > / > application > > all of the conditional logic for assigning groups of params to nodes > should only be written once. After that, changes should just involve > configuration.I agree, however, 100 lines of code to achieve this the way extlookup does, I''d very much love a node tool like this, but it would be a long painful process of coding, bug fixing etc.> I disagree with this assumption. I think that with a node tool (ifs > its written correctly), you would just have to choose the groups of > params that you want to use. If your requirements change, then just > reassign a different group of parameters (or change 1 of the param > values for a group).there''s no such tool - at least not in public domain, again I agree with you but it would take ages to write a fully flexible node tool, foreman and dashboard both suffer from a lot of assumption about how the authors/designers thinks architectures should work that doesn''t translate well to all cases.> with extlookup you just configure it in one line of config. > > > Wouldnt there be cases where you have to change every line of puppet > code that uses the extlookup tool if the properties that determine the > lookup change?not that I can think of.> I have this idea that the ideal solution is a combination of using > both an external node classifier as well as an extlookup tool. > > The classifier handles the assignment of gorups of params based on > inheritance. > > Most param information is determined by some external feature of a > node. What site am I at? What DC? What subnet? What is my role? These > params should be assigned by an external node classifier. This allows > us to control how these values are assigned outside of the scope of > our puppet code.These are facts about a node, it should be on the node and it has a lot of use being on the node (see how mcollective does discovery for example). though that said, nothing prevents you from just writing a list of classifier provided facts onto the node to achieve the same.> Some param information is always determined by some fact about our > node (think platform). These types of params should be set with an > extlookup tool (or something similar). This extlookup tool should just > be accessing config from some kind of per module config fille. Think > about how strings vary between platform, arch, fact an an > internationalization problem.> file{''ssh'': > name => extlookup(ssh-name, $operatingsystem) > }there''s stuff that extlookup can do that no node classifer can do in the current model, extlookup has access to the existing scope, you could lookup $ntpserver from extlookup in one class and get one answer while in another class you''d get another based on variables and values in scope at the specific time. a bit contrived in this example but it has uses. something where i find extlookup invaluable is with package management: define mypkg() { $ver = extlookup("package_${name}", "present") package{$name: ensure => $ver} } mypkg{"puppet": } I can now like I often do when new puppets come out just configure my development environment to go to the next version, then I''d do machines in the states, then uk and za and finally germany all by just adjusting the data. Or one specific client insist on having screen on his machines, no problem extlookup search for my $client fact and i can enable screen just for him by manipulating the data only - this kind of flexibility is invaluable in sites like mine where I host 10s of customers worth of kit on the same master. -- R.I.Pienaar -- 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.
Hi, On Sun, Feb 14, 2010 at 5:38 PM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > > with regards to scope, its possible that extlookup is more reliable > > since it determines the value for the config inline, thus removing any > > chance that a global variable assiged from the classifier would be > > overridden from an enclosing scope. This scoping issue for the > > external node classifier can be solved by namespacing the params, I > > used my_ for this (although this wouldnt work well when classes will > > have constructors in Rwolf) > > sure, but it just shows why global variables have been abandoned by all but > the most sucky devs and languages, puppet has some way to go to make this > easy for us to do the right thing :) >I wish I had a better response for this point ;) Except I will say that something feels natural about injecting parameters into a puppet run (maybe thats what other global variable supporters would say).> > In my view, they are functionally equivalent an even similar. They > > both rely on code that looks up params from an external source. The > > external node classifier does it before the puppet run then applies > > the params at top scope, where extlookup determines the information in > > your puppet code. > > > for me the simplicity of how extlookup does it appeals, 100 lines to have > something that achieves this compared to super complex node classifiers. > > > There are ways to access facts from an external node classifier. > > Namely, by parsing the $varlib/nodes/facts/HOSTNAME.yaml file (which > > is guarenteed to be created before your external node classifier is > > run) I agree this is not the cleanest way to do this, and have even > > opened a ticket several months ago > > http://projects.reductivelabs.com/issues/2356 (before I worked at RL:) > > yeah, hacky though, I wouldnt suggest that a node classifier being on the > same box as the master is a good idea. >I agree that could have some risk, or further abuse constrained CPUS. The concept can still be salvaged by putting the nodes dir on a shared filesystem.> > I see this a little differently: the node tool needs a way to assign > > which groups of params should be assigned to which nodes. The groups > > of params should support inheritence. > > > > default > > / \ > > site 1 site 2 > > / > > subnet 1 > > / > > application > > > > all of the conditional logic for assigning groups of params to nodes > > should only be written once. After that, changes should just involve > > configuration. > > I agree, however, 100 lines of code to achieve this the way extlookup does, > I''d very much love a node tool like this, but it would be a long painful > process of coding, bug fixing etc. >I''ve written one before, it wasn''t that difficult. I unfortunately don''t own the IP. I agree that there needs to be an existing implementation of this, and that its crazy for everyone to write their own (even though I had fun writing mine :)). That part of my code was def less than 100 lines of ruby code. This feature (managing groups of params) is the basic concept behind The Dashboard, although it clearly needs a cleaner interface and a little more work.> > > I disagree with this assumption. I think that with a node tool (ifs > > its written correctly), you would just have to choose the groups of > > params that you want to use. If your requirements change, then just > > reassign a different group of parameters (or change 1 of the param > > values for a group). > > there''s no such tool - at least not in public domain, again I agree with > you but it would take ages to write a fully flexible node tool, foreman and > dashboard both suffer from a lot of assumption about how the > authors/designers thinks architectures should work that doesn''t translate > well to all cases. >The Dashboard is supposed to be this tool. Can you be specific about what you think those limitations are?> > > with extlookup you just configure it in one line of config. > > > > > > Wouldnt there be cases where you have to change every line of puppet > > code that uses the extlookup tool if the properties that determine the > > lookup change? > > not that I can think of. >when I say properties, I mean, its no longer determined by DC, but by some other fact.> > > I have this idea that the ideal solution is a combination of using > > both an external node classifier as well as an extlookup tool. > > > > The classifier handles the assignment of gorups of params based on > > inheritance. > > > > Most param information is determined by some external feature of a > > node. What site am I at? What DC? What subnet? What is my role? These > > params should be assigned by an external node classifier. This allows > > us to control how these values are assigned outside of the scope of > > our puppet code. > > These are facts about a node, it should be on the node and it has a lot of > use being on the node (see how mcollective does discovery for example). > though that said, nothing prevents you from just writing a list of > classifier provided facts onto the node to achieve the same. >thats an interesting point. How are you handle those facts? Do you keep a description of the location of machines on the local filesystem? Or is ipaddress enough to create these facts?> Some param information is always determined by some fact about our > > node (think platform). These types of params should be set with an > > extlookup tool (or something similar). This extlookup tool should just > > be accessing config from some kind of per module config fille. Think > > about how strings vary between platform, arch, fact an an > > internationalization problem. > > > file{''ssh'': > > name => extlookup(ssh-name, $operatingsystem) > > } > > there''s stuff that extlookup can do that no node classifer can do in the > current model, extlookup has access to the existing scope, you could lookup > $ntpserver from extlookup in one class and get one answer while in another > class you''d get another based on variables and values in scope at the > specific time. > > a bit contrived in this example but it has uses. > > something where i find extlookup invaluable is with package management: > > define mypkg() { > $ver = extlookup("package_${name}", "present") > > package{$name: ensure => $ver} > } > > mypkg{"puppet": } >that example above was supposed to be package and not file ;)> > I can now like I often do when new puppets come out just configure my > development environment to go to the next version, then I''d do machines in > the states, then uk and za and finally germany all by just adjusting the > data. Or one specific client insist on having screen on his machines, no > problem extlookup search for my $client fact and i can enable screen just > for him by manipulating the data only - this kind of flexibility is > invaluable in sites like mine where I host 10s of customers worth of kit on > the same master. > > when I envision param groups, params related to hostname are at the bottom(as in they are not overriden)> > > -- > R.I.Pienaar > > -- > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-Dan -- 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 Mon, Feb 15, 2010 at 1:08 AM, Nat <qwerty.nat@gmail.com> wrote:> > 3. forman and dashboard - there are not really feasible at the moment > due to our current set up with our external node data store >Not sure if it helps, but foreman can import the data from your existing external node tools: http://theforeman.org/wiki/foreman/External_Nodes#Import-your-external-node-setup-from-an-older-external-node-setup Cheers, Ohad -- 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.
----- "Dan Bode" <dan@reductivelabs.com> wrote:>> sure, but it just shows why global variables have been abandoned by >> all but the most sucky devs and languages, puppet has some way to go >> to make this easy for us to do the right thing :) > > > I wish I had a better response for this point ;) Except I will say > that something feels natural about injecting parameters into a puppet > run (maybe thats what other global variable supporters would say).I don''t think it''s the end of the world too right now, but puppet needs a lot of work to get to the point where we can really start sharing modules as a group. This is one of them and the work is ongoing so thats encouraging> there''s no such tool - at least not in public domain, again I agree > with you but it would take ages to write a fully flexible node tool, > foreman and dashboard both suffer from a lot of assumption about how > the authors/designers thinks architectures should work that doesn''t > translate well to all cases. > > The Dashboard is supposed to be this tool. > Can you be specific about what you think those limitations are?I need another look at it, it''s been a while and I forget the specifics of what it was.> > Wouldnt there be cases where you have to change every line of puppet > > code that uses the extlookup tool if the properties that determine > the > > lookup change? > > not that I can think of. > > > when I say properties, I mean, its no longer determined by DC, but by > some other fact.that''s fine - you have one place where you configure the lookup ordering - in site.pp in the global scope - and if you want to change you change the config not the extlookup calls.>> These are facts about a node, it should be on the node and it has a >> lot of use being on the node (see how mcollective does discovery for >> example). though that said, nothing prevents you from just writing a >> list of classifier provided facts onto the node to achieve the same. > > > thats an interesting point. How are you handle those facts? Do you > keep a description of the location of machines on the local > filesystem? Or is ipaddress enough to create these facts?it varies, these are some of my facts: country = dynamic location = dynamic by way of a nasty case statement on ips environment = saved on the box in a text file dom0 (fqdn of my dom0) = put there during kickstart customer = saved on the box in a text file, easy to do in ks too -- 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.
I''m going to ask what might be a dumb question now. Why can''t we re-order things such that the external node classifier doesn''t simply get a certname as an argument, but instead receives all the client facts? There is an awful lot of logic I would like to remove from my manifests and push to the external node classifier, and all of this logic is based upon fact values. If we could do this, even if it required that the external node classifier be written in Ruby and made use of the puppet libraries, it would significantly improve the functionality of external node classifiers in my opinion. -- 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.
probably dumb answer - use foreman as it includes the facts already ;) feature requests are welcomed cheers, Ohad On Tue, Feb 16, 2010 at 5:51 PM, Nigel Kersten <nigelk@google.com> wrote:> I''m going to ask what might be a dumb question now. > > Why can''t we re-order things such that the external node classifier > doesn''t simply get a certname as an argument, but instead receives all > the client facts? > > There is an awful lot of logic I would like to remove from my > manifests and push to the external node classifier, and all of this > logic is based upon fact values. > > If we could do this, even if it required that the external node > classifier be written in Ruby and made use of the puppet libraries, it > would significantly improve the functionality of external node > classifiers in my opinion. > > -- > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- 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 Tue, Feb 16, 2010 at 8:19 AM, Ohad Levy <ohadlevy@gmail.com> wrote:> probably dumb answer - use foreman as it includes the facts already ;)but if I understand Foreman correctly, it''s getting these from the cached version server-side right? Either locally or as part of a task from other puppet servers? This means it''s not going to have these facts until the client has completed at least one puppet run right?> feature requests are welcomed > cheers, > Ohad > > On Tue, Feb 16, 2010 at 5:51 PM, Nigel Kersten <nigelk@google.com> wrote: >> >> I''m going to ask what might be a dumb question now. >> >> Why can''t we re-order things such that the external node classifier >> doesn''t simply get a certname as an argument, but instead receives all >> the client facts? >> >> There is an awful lot of logic I would like to remove from my >> manifests and push to the external node classifier, and all of this >> logic is based upon fact values. >> >> If we could do this, even if it required that the external node >> classifier be written in Ruby and made use of the puppet libraries, it >> would significantly improve the functionality of external node >> classifiers in my opinion. >> >> -- >> 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. >> > > -- > 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. >-- nigel -- 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.
thats correct, foreman will import the facts as soon as they have been written to the yaml dir (or if you are using store config as soon as they are written to the db by puppet). in foreman deployment scenario, the first time puppet runs is only to fetch the certificates (e.g. in OS post install), so it can work. but you are correct that this is a limitation if your facts change often. btw: the same problem exists with normal external nodes which query the local yaml files :( Ohad On Tue, Feb 16, 2010 at 6:22 PM, Nigel Kersten <nigelk@google.com> wrote:> On Tue, Feb 16, 2010 at 8:19 AM, Ohad Levy <ohadlevy@gmail.com> wrote: > > probably dumb answer - use foreman as it includes the facts already ;) > > but if I understand Foreman correctly, it''s getting these from the > cached version server-side right? Either locally or as part of a task > from other puppet servers? > > This means it''s not going to have these facts until the client has > completed at least one puppet run right? > > > > > feature requests are welcomed > > cheers, > > Ohad > > > > On Tue, Feb 16, 2010 at 5:51 PM, Nigel Kersten <nigelk@google.com> > wrote: > >> > >> I''m going to ask what might be a dumb question now. > >> > >> Why can''t we re-order things such that the external node classifier > >> doesn''t simply get a certname as an argument, but instead receives all > >> the client facts? > >> > >> There is an awful lot of logic I would like to remove from my > >> manifests and push to the external node classifier, and all of this > >> logic is based upon fact values. > >> > >> If we could do this, even if it required that the external node > >> classifier be written in Ruby and made use of the puppet libraries, it > >> would significantly improve the functionality of external node > >> classifiers in my opinion. > >> > >> -- > >> 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > >> For more options, visit this group at > >> http://groups.google.com/group/puppet-users?hl=en. > >> > > > > -- > > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > nigel > > -- > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- 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 Tue, Feb 16, 2010 at 8:33 AM, Ohad Levy <ohadlevy@gmail.com> wrote:> thats correct, foreman will import the facts as soon as they have been > written to the yaml dir (or if you are using store config as soon as they > are written to the db by puppet). > in foreman deployment scenario, the first time puppet runs is only to fetch > the certificates (e.g. in OS post install), so it can work. > but you are correct that this is a limitation if your facts change often. > btw: the same problem exists with normal external nodes which query the > local yaml files :(Exactly. This is why I''d like to see if we could change the ordering though. It''s a bit of a problem, as if we''re distributing facts as plugins in modules in environments.... and we''re using the external node classifier to *set* the environment.... we have a chicken or the egg problem. I''m not sure what the best solution is here, but I have a very mobile user base that reasonably frequently switch between different puppet servers based upon their location, so the "first puppet run against a given server" scenario is something I have to be concerned about.> Ohad > > On Tue, Feb 16, 2010 at 6:22 PM, Nigel Kersten <nigelk@google.com> wrote: >> >> On Tue, Feb 16, 2010 at 8:19 AM, Ohad Levy <ohadlevy@gmail.com> wrote: >> > probably dumb answer - use foreman as it includes the facts already ;) >> >> but if I understand Foreman correctly, it''s getting these from the >> cached version server-side right? Either locally or as part of a task >> from other puppet servers? >> >> This means it''s not going to have these facts until the client has >> completed at least one puppet run right? >> >> >> >> > feature requests are welcomed >> > cheers, >> > Ohad >> > >> > On Tue, Feb 16, 2010 at 5:51 PM, Nigel Kersten <nigelk@google.com> >> > wrote: >> >> >> >> I''m going to ask what might be a dumb question now. >> >> >> >> Why can''t we re-order things such that the external node classifier >> >> doesn''t simply get a certname as an argument, but instead receives all >> >> the client facts? >> >> >> >> There is an awful lot of logic I would like to remove from my >> >> manifests and push to the external node classifier, and all of this >> >> logic is based upon fact values. >> >> >> >> If we could do this, even if it required that the external node >> >> classifier be written in Ruby and made use of the puppet libraries, it >> >> would significantly improve the functionality of external node >> >> classifiers in my opinion. >> >> >> >> -- >> >> 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. >> >> >> > >> > -- >> > 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. >> > >> >> >> >> -- >> nigel >> >> -- >> 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. >> > > -- > 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. >-- nigel -- 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.