Hi all, I''m looking at changing the operatingsystemrelease fact for Red Hat. Linux currently just uses the kernel release as the operating system release, but I''ve got a client who wants the release to have both the specific distro (e.g., AS or EL) and the release (e.g., 3 or 4). Will this particularly annoy anyone? Anyone want to help make the release string work on other Linux distributions? -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
On Aug 29, 2006, at 9:31 AM, Luke Kanies wrote:> Hi all, > > I''m looking at changing the operatingsystemrelease fact for Red Hat. > Linux currently just uses the kernel release as the operating system > release, but I''ve got a client who wants the release to have both the > specific distro (e.g., AS or EL) and the release (e.g., 3 or 4). > > Will this particularly annoy anyone? Anyone want to help make the > release string work on other Linux distributions?I think this makes sense for Linux systems, given the separation of kernel and the rest of the system. However, having two facts for this because redhat does it that way doesn''t seem like it''s a very robust solution. Perhaps we could have a fact for ''additional distro data'', which could include information beyond the actual release number? This would make sense for systems like Ubuntu as well, where Kubuntu/Edubuntu/etc could fill that spot. -- Erik Hollensbe erik@hollensbe.org
On Tue, Aug 29, 2006 at 09:31:08AM -0700, Luke Kanies wrote:> Hi all, > > I''m looking at changing the operatingsystemrelease fact for Red Hat. > Linux currently just uses the kernel release as the operating system > release, but I''ve got a client who wants the release to have both the > specific distro (e.g., AS or EL) and the release (e.g., 3 or 4).I would prefer not to have AS|WS|WS in operatingsystemreleases since I suspect that in the future I''ll have to write code like if( $operatingsystemrelease > 4 ) { ... } or something similar.> Will this particularly annoy anyone? Anyone want to help make the > release string work on other Linux distributions?Using lsb_release -r for operatingsystemrelease and lsb_release -i for operatingsystem should be OK for most Linux distributions. Some examples for Fedora|RHEL: Fedora Core 5: $ lsb_release -i Distributor ID: FedoraCore $ lsb_release -r Release: 5 RHEL AS 4: $ lsb_release -i Distributor ID: RedHatEnterpriseAS $ lsb_release -r Release: 4 RHEL WS 4: $ lsb_release -i Distributor ID: RedHatEnterpriseWS $ lsb_release -r Release: 4
On Aug 29, 2006, at 9:54 AM, Kostas Georgiou wrote:> > I would prefer not to have AS|WS|WS in operatingsystemreleases since I > suspect that in the future I''ll have to write code like > > if( $operatingsystemrelease > 4 ) { > ... > } > or something similar.Should I make a different fact for the RH distro or whatever it''s called, then? And do you want the update number in there?> > Using lsb_release -r for operatingsystemrelease and lsb_release -i for > operatingsystem should be OK for most Linux distributions.The problem with lsb_release is that it''s not always available. It''s not installed by default on Debian, for instance. So if it''s available it should probably be used, but we can''t assume it exists.> Some examples for Fedora|RHEL: > > Fedora Core 5: > $ lsb_release -i > Distributor ID: FedoraCore > $ lsb_release -r > Release: 5 > > RHEL AS 4: > $ lsb_release -i > Distributor ID: RedHatEnterpriseAS > $ lsb_release -r > Release: 4 > > RHEL WS 4: > $ lsb_release -i > Distributor ID: RedHatEnterpriseWS > $ lsb_release -r > Release: 4I guess we need to turn all of lsb_release''s output into as many facts as possible. There are a few bugs and feature requests in Facter right now, so when I have some time (which looks to be not all that soon), I can go through and try to add all of this. If someone''s been looking for an excuse to start contributing, though, Facter is a very simple library and would be a great place to start. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
On Tue, Aug 29, 2006 at 10:01:23AM -0700, Luke Kanies wrote:> On Aug 29, 2006, at 9:54 AM, Kostas Georgiou wrote: > > > > I would prefer not to have AS|WS|WS in operatingsystemreleases since I > > suspect that in the future I''ll have to write code like > > > > if( $operatingsystemrelease > 4 ) { > > ... > > } > > or something similar. > > Should I make a different fact for the RH distro or whatever it''s > called, then? > > And do you want the update number in there?Good question, it''s not usefull to me but some people will want it available. Not sure what the best way to report it is, it would be nice if you get similar facts under all the RHEL clones (Centos for example).> > Using lsb_release -r for operatingsystemrelease and lsb_release -i for > > operatingsystem should be OK for most Linux distributions. > > The problem with lsb_release is that it''s not always available. It''s > not installed by default on Debian, for instance. So if it''s > available it should probably be used, but we can''t assume it exists.I assume that most people that will use puppet in linux are using some form of package managment so puppet can require lsb_release. Yes I know this isn''t always the case :(> I guess we need to turn all of lsb_release''s output into as many > facts as possible.https://reductivelabs.com/cgi-bin/facter.cgi/ticket/21 Kostas
On Tue, Aug 29, 2006 at 10:01:23AM -0700, Luke Kanies wrote:> On Aug 29, 2006, at 9:54 AM, Kostas Georgiou wrote: > > > > I would prefer not to have AS|WS|WS in operatingsystemreleases since I > > suspect that in the future I''ll have to write code like > > > > if( $operatingsystemrelease > 4 ) { > > ... > > } > > or something similar. > > Should I make a different fact for the RH distro or whatever it''s > called, then?I wonder if there should be a set of RedHatThis and RedHatThat facts for this when OperatingSystem == ''RedHat''. There''s already the Architecture fact (that''s quite Debian-specific at present), so we''ve got a precedent. The problem with trying to generalise the versioning info is that different distros (and OSes) have different ideas for all this sort of thing, so there won''t be a set of names that match perfectly for everyone. The only way out of this, that I can see, is to strictly define what *we* mean by, for example, "OperatingSystemRelease", and then try and shoehorn various distributors'' ideas into that model.> > Using lsb_release -r for operatingsystemrelease and lsb_release -i for > > operatingsystem should be OK for most Linux distributions. > > The problem with lsb_release is that it''s not always available. It''s > not installed by default on Debian, for instance.<fx: Places Debian maintainer hat on, at a jaunty angle> A quick Depends: modification could make that problem go away, though.> So if it''s > available it should probably be used, but we can''t assume it exists.I think some LSB facts wouldn''t go astray. Might also be handy for the four people in the world who actually want to use the features of the LSB only to stay distro-independent.> If someone''s been looking for an excuse to start contributing, > though, Facter is a very simple library and would be a great place to > start.I heartily endorse this sentiment. Facter is simple to extend. It''s how I started, and now look at me -- I almost sound like I know what I''m talking about! <grin> - Matt
On Wed, Aug 30, 2006 at 06:32:19AM +1000, Matthew Palmer wrote:> On Tue, Aug 29, 2006 at 10:01:23AM -0700, Luke Kanies wrote: > > On Aug 29, 2006, at 9:54 AM, Kostas Georgiou wrote: > > > > > > I would prefer not to have AS|WS|WS in operatingsystemreleases since I > > > suspect that in the future I''ll have to write code like > > > > > > if( $operatingsystemrelease > 4 ) { > > > ... > > > } > > > or something similar. > > > > Should I make a different fact for the RH distro or whatever it''s > > called, then? > > I wonder if there should be a set of RedHatThis and RedHatThat facts for > this when OperatingSystem == ''RedHat''. There''s already the Architecture > fact (that''s quite Debian-specific at present), so we''ve got a precedent.Maybe we need to extent facts to something more than just strings. I can imagine cases when you only just care if you run under Linux and cases where you care if it''s RHEL, RHEL WS, RHEL WS 4 or RHEL WS 4 update4. So instead of: rhelfactX = "RHEL" rhelfactXX = "RHEL WS" rhelfactXXX = "RHEL WS 4" rhelfactXXXX = "RHEL WS 4 update4" you have rhelfact = [ "RHEL", "RHEL WS", "RHEL WS 4", "RHEL WS 4 update4" ] or something similar. Kostas
> Maybe we need to extent facts to something more than just strings. I can > imagine cases when you only just care if you run under Linux and cases > where you care if it''s RHEL, RHEL WS, RHEL WS 4 or RHEL WS 4 update4. So > instead of: > rhelfactX = "RHEL" > rhelfactXX = "RHEL WS" > rhelfactXXX = "RHEL WS 4" > rhelfactXXXX = "RHEL WS 4 update4" > you have > rhelfact = [ "RHEL", "RHEL WS", "RHEL WS 4", "RHEL WS 4 update4" ] > or something similar. >This would certainly be useful. What is the Puppet syntax that you use to test for something in this sort of structure (as in "array has an element equal to").
On Tue, Aug 29, 2006 at 11:33:35PM -0700, Digant C Kasundra wrote:> > Maybe we need to extent facts to something more than just strings. I can > > imagine cases when you only just care if you run under Linux and cases > > where you care if it''s RHEL, RHEL WS, RHEL WS 4 or RHEL WS 4 update4. So > > instead of: > > rhelfactX = "RHEL" > > rhelfactXX = "RHEL WS" > > rhelfactXXX = "RHEL WS 4" > > rhelfactXXXX = "RHEL WS 4 update4" > > you have > > rhelfact = [ "RHEL", "RHEL WS", "RHEL WS 4", "RHEL WS 4 update4" ] > > or something similar. > > > > This would certainly be useful. What is the Puppet syntax that you use to > test for something in this sort of structure (as in "array has an element > equal to").You don''t, that''s why Facter is very string-only. I''ve got some tests in a Facter branch locally that checks that Facter can handle structured data (and print it properly when run on the command line) that I have to finish and submit. Then, once we know Facter is clean, we can start looking at how to extend Puppet to handle such things. - Matt -- <FreeFrag> The most secure computer in the world is one not connected to the internet. Thats why I recommend Telstra ADSL. -- bash.org/?168859
On Aug 29, 2006, at 11:33 PM, Digant C Kasundra wrote:>> Maybe we need to extent facts to something more than just strings. >> I can >> imagine cases when you only just care if you run under Linux and >> cases >> where you care if it''s RHEL, RHEL WS, RHEL WS 4 or RHEL WS 4 >> update4. So >> instead of: >> rhelfactX = "RHEL" >> rhelfactXX = "RHEL WS" >> rhelfactXXX = "RHEL WS 4" >> rhelfactXXXX = "RHEL WS 4 update4" >> you have >> rhelfact = [ "RHEL", "RHEL WS", "RHEL WS 4", "RHEL WS 4 update4" ] >> or something similar. >> > > This would certainly be useful. What is the Puppet syntax that you > use to > test for something in this sort of structure (as in "array has an > element > equal to").There''s the rub -- there is no such syntax. So, any non-string facts are basically useless to Puppet at this point. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
On Tue, 2006-08-29 at 09:31 -0700, Luke Kanies wrote:> I''m looking at changing the operatingsystemrelease fact for Red Hat. > Linux currently just uses the kernel release as the operating system > release, but I''ve got a client who wants the release to have both the > specific distro (e.g., AS or EL) and the release (e.g., 3 or 4). > > Will this particularly annoy anyone? Anyone want to help make the > release string work on other Linux distributions?It''s definitely a mess, particularly if you start thinking about distros derived from other distros and trying to fit them all into one scheme; to make matters worse, e.g. RHEL officially uses a scheme like ''RHEL $VARIANT release $REL ($NAME Update $U)'' whereas Centos calls the same thing ''Centos $REL.$U'' so that RHEL AS/WS/ES release 4 update 3 becomes Centos 4.3 (they do away with the distinction between variants since that largely just distinguishes between the support levels you get with your RHEL subscription) And it''s likely that the versioning scheme will be changed for RHEL 5 ;) This all reminds me of the trials and tribulations people go through to make C code portable: depending on what features a platform supports, you need to enable the ''right'' piece of code with an #if. One way to do this is to make the choices platform-dependent: #if SOLARIS .. Solaris code #endif #if LINUX .. Linux code #endif That generally leads to hugely unmaintainable code, that is also less portable than it could be. A much better approach is to make the ifdef''s depend on features of the platform and test for them, so that the above might become #if HAVE_INET_ATON .. code that uses inet_aton #endif #if HAVE_INET_ADDR .. code that uses inet_addr #endif That''s the style strongly encouraged by autoconf. What does that mean for facter and the use of facts in manifests ? Instead of having facter report the OS release, and then using rpm if it''s a Red Hat OS, and apt if it''s a Debian based OS, we should try to build a standard set of facts that tests features of the client and then reports things like ''has_rpm'' and ''has_apt'' so that manifests can make decisions without inferring properties from some other fact. Instead of a bunch of boolean has_* facts, it might be more useful to split the facts into pretty focused categories with a well-known set of values, e.g. use a ''pkgformat'' fact with possible values ''rpm'' and ''apt'' (are there others ? ;) That of course will only be useful if we can actually collect a pretty broad set of features that people need to base their decisions on in manifests, and add them to facter - send patches ;) David
On Thu, Sep 07, 2006 at 07:28:13PM -0700, David Lutterkort wrote:> e.g. use a ''pkgformat'' fact with possible values ''rpm'' and ''apt'' (are > there others ? ;)/me hides behind something Gentoo-fanatic proof I totally agree with everything you said, BTW. Capabilities-based detection is far more useful than inferring everything from the identity of the system. We''ll have to be careful to avoid the recently reported problem of a Gentoo system detecting /usr/bin/rpm and getting a little assumptive, though. - Matt
On 9/7/06, David Lutterkort <dlutter@redhat.com> wrote:> On Tue, 2006-08-29 at 09:31 -0700, Luke Kanies wrote: > > I''m looking at changing the operatingsystemrelease fact for Red Hat. > > Linux currently just uses the kernel release as the operating system > > release, but I''ve got a client who wants the release to have both the > > specific distro (e.g., AS or EL) and the release (e.g., 3 or 4). > > > > Will this particularly annoy anyone? Anyone want to help make the > > release string work on other Linux distributions? > > It''s definitely a mess, particularly if you start thinking about distros > derived from other distros and trying to fit them all into one scheme; > to make matters worse, e.g. RHEL officially uses a scheme like ''RHEL > $VARIANT release $REL ($NAME Update $U)'' whereas Centos calls the same > thing ''Centos $REL.$U'' so that RHEL AS/WS/ES release 4 update 3 becomes > Centos 4.3 (they do away with the distinction between variants since > that largely just distinguishes between the support levels you get with > your RHEL subscription) And it''s likely that the versioning scheme will > be changed for RHEL 5 ;) >The ''madness'' of trying to detect the following [not official names, but ones we needed to deal with various projects.] RHEL-3.7.0{AS,ES,WS} RHEL-3.8.0{AS,ES,WS} RHEL-4.2.0{AS,ES,WS} RHEL-4.4.0{AS,ES,WS} SCIL-4.1.9 [Scientific Linux with security updates based around 4.1 version] While the config files being put out were the same.. there were ''hot-fixes'' that might get put into one set but not another. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"
2006/9/8, Matthew Palmer <mpalmer@hezmatt.org>:> > On Thu, Sep 07, 2006 at 07:28:13PM -0700, David Lutterkort wrote: > > e.g. use a ''pkgformat'' fact with possible values ''rpm'' and ''apt'' (are > > there others ? ;)portage, portage, portage :o) /me hides behind something Gentoo-fanatic proof mmmm... you were talking about me, weren''t you? :oP I totally agree with everything you said, BTW. Capabilities-based detection> is far more useful than inferring everything from the identity of the > system. We''ll have to be careful to avoid the recently reported problem > of > a Gentoo system detecting /usr/bin/rpm and getting a little assumptive, > though. >I think this is just a problem of making this fact discovery a bit more "intelligent". In my case, I had installed the rpm executable (I even think I installed it to take a look at the Red Hat init scripts and configuration files for puppet), so facter/puppet assumed that rpm would be a valid package manager/provider for my system. Maybe this discovery could be based in something more specific, kind of searching for the executable and its corresponding package database (I guess Red Hat has something like this?). In Gentoo I guess this would be as easy as checking for the emerge executable, and the /var/lib/portage/world file (the file that stores all the explicitly installed packages) or the /var/db/pkg directory (the directory where all the information about installed packages is stored). If you find the executable but that file or directory are missing, you either have a broken Gentoo, or a system that is not a Gentoo one. I guess the same could be done for other systems. Best regards Jose _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Fri, Sep 08, 2006 at 09:05:13PM +0200, José González Gómez wrote:> 2006/9/8, Matthew Palmer <mpalmer@hezmatt.org>: > > /me hides behind something Gentoo-fanatic proof > > mmmm... you were talking about me, weren''t you? :oPNot really -- you''re a Gentoo user, just like I''m a Debian/Ubuntu user. I was thinking more of some of the real Gentoo fanboys I''ve met over the years, who were just completely incapable of acknowledging that some of Gentoo''s perceived advantages weren''t universally applicable. I cringed at the thought of the rain of vitriol that would result if any of them took David''s comment seriously. That isn''t to say that there aren''t similarly "energetic" advocates for other distributions (and Operating Systems, to boot).> I totally agree with everything you said, BTW. Capabilities-based detection > >is far more useful than inferring everything from the identity of the > >system. We''ll have to be careful to avoid the recently reported problem > >of > >a Gentoo system detecting /usr/bin/rpm and getting a little assumptive, > >though. > > I think this is just a problem of making this fact discovery a bit more > "intelligent". In my case, I had installed the rpm executable (I even think > I installed it to take a look at the Red Hat init scripts and configuration > files for puppet), so facter/puppet assumed that rpm would be a valid > package manager/provider for my system. Maybe this discovery could be based > in something more specific, kind of searching for the executable and its > corresponding package database (I guess Red Hat has something like this?).That''s a good idea. Yes, RedHat has database of installed packages, I just can''t remember where exactly it lives. - Matt
On Sep 8, 2006, at 2:00 PM, Matthew Palmer wrote:> >> I totally agree with everything you said, BTW. Capabilities-based >> detection >>> is far more useful than inferring everything from the identity of >>> the >>> system. We''ll have to be careful to avoid the recently reported >>> problem >>> of >>> a Gentoo system detecting /usr/bin/rpm and getting a little >>> assumptive, >>> though. >> >> I think this is just a problem of making this fact discovery a bit >> more >> "intelligent". In my case, I had installed the rpm executable (I >> even think >> I installed it to take a look at the Red Hat init scripts and >> configuration >> files for puppet), so facter/puppet assumed that rpm would be a valid >> package manager/provider for my system. Maybe this discovery could >> be based >> in something more specific, kind of searching for the executable >> and its >> corresponding package database (I guess Red Hat has something like >> this?). > > That''s a good idea. Yes, RedHat has database of installed > packages, I just > can''t remember where exactly it lives.Maybe I deleted it before I posted it yesterday, but the YAML solution to facter that I was talking about the other day (where YAML can override facter facts) would solve this rather well, given a "packagemanager" fact of some sort. Those of us who use FreeBSD would be delighted to know that we could use RPM for linux-compat situations (as that''s what the linux-compat suite uses in a lot of cases). Well, at least me. :) -- Erik Hollensbe erik@hollensbe.org
On Sat, Sep 09, 2006 at 07:00:35AM +1000, Matthew Palmer wrote:> On Fri, Sep 08, 2006 at 09:05:13PM +0200, José González Gómez wrote: > > > > I think this is just a problem of making this fact discovery a bit more > > "intelligent". In my case, I had installed the rpm executable (I even think > > I installed it to take a look at the Red Hat init scripts and configuration > > files for puppet), so facter/puppet assumed that rpm would be a valid > > package manager/provider for my system. Maybe this discovery could be based > > in something more specific, kind of searching for the executable and its > > corresponding package database (I guess Red Hat has something like this?). > > That''s a good idea. Yes, RedHat has database of installed packages, I just > can''t remember where exactly it lives.$ ls /var/lib/rpm/ Basenames __db.003 Installtid Provideversion Sha1header Conflictname Dirnames Name Pubkeys Sigmd5 __db.001 Filemd5s Packages Requirename Triggername __db.002 Group Providename Requireversion I have no idea if you do get a database as well in another distro/OS if you install rpm though. Checking that both rpm and /var/lib/rpm/Packages exist isn''t going to hurt in any case. Kostas Georgiou
On Fri, 2006-09-08 at 22:41 +0100, Kostas Georgiou wrote:> I have no idea if you do get a database as well in another distro/OS > if you install rpm though. Checking that both rpm and /var/lib/rpm/Packages > exist isn''t going to hurt in any case.If you don''t, your rpm installation will be pretty much useless, since there is little useful that rpm can do without the DB (mainly, just inspect packages) So checking for /usr/bin/rpm and /var/lib/rpm/Packages (or that ''rpm -q rpm'' returns something reasonable) should be a pretty good indication that rpm is being used. David
On Fri, Sep 08, 2006 at 02:54:28PM -0700, David Lutterkort wrote:> On Fri, 2006-09-08 at 22:41 +0100, Kostas Georgiou wrote: > > I have no idea if you do get a database as well in another distro/OS > > if you install rpm though. Checking that both rpm and /var/lib/rpm/Packages > > exist isn''t going to hurt in any case. > > If you don''t, your rpm installation will be pretty much useless, since > there is little useful that rpm can do without the DB (mainly, just > inspect packages) > > So checking for /usr/bin/rpm and /var/lib/rpm/Packages (or that ''rpm -q > rpm'' returns something reasonable) should be a pretty good indication > that rpm is being used.If the database is locked because there is a lengthy update in progress or there are problems with the database rpm -q ... might take a while to return if ever. I haven''t seen any database problems since rh9 which it used to leave the database in a bad state fairly often and you had to rebuild it every couple of weeks. For this reason I''ll prefer not have rpm -q running every time, after all you might not have any package statements in your manifests so there is no reason for puppet to wait until it gets a lock in the database. Kostas Georgiou
On Fri, 8 Sep 2006, Kostas Georgiou wrote:> On Fri, Sep 08, 2006 at 02:54:28PM -0700, David Lutterkort wrote: > >> On Fri, 2006-09-08 at 22:41 +0100, Kostas Georgiou wrote: >>> I have no idea if you do get a database as well in another distro/OS >>> if you install rpm though. Checking that both rpm and /var/lib/rpm/Packages >>> exist isn''t going to hurt in any case. >> >> If you don''t, your rpm installation will be pretty much useless, since >> there is little useful that rpm can do without the DB (mainly, just >> inspect packages) >> >> So checking for /usr/bin/rpm and /var/lib/rpm/Packages (or that ''rpm -q >> rpm'' returns something reasonable) should be a pretty good indication >> that rpm is being used. > > If the database is locked because there is a lengthy update in progress > or there are problems with the database rpm -q ... might take a while > to return if ever. I haven''t seen any database problems since rh9 which > it used to leave the database in a bad state fairly often and you had > to rebuild it every couple of weeks. > > For this reason I''ll prefer not have rpm -q running every time, after > all you might not have any package statements in your manifests so there > is no reason for puppet to wait until it gets a lock in the database.All the recent (and not so recent) versions of RedHat & Fedora have a daily cron that writes the list of installed RPMs to /var/log/rpmpkgs. (/etc/cron.daily/rpm) -sharif
On Sep 8, 2006, at 2:40 PM, Erik Hollensbe wrote:> > Maybe I deleted it before I posted it yesterday, but the YAML > solution to facter that I was talking about the other day (where YAML > can override facter facts) would solve this rather well, given a > "packagemanager" fact of some sort. > > Those of us who use FreeBSD would be delighted to know that we could > use RPM for linux-compat situations (as that''s what the linux-compat > suite uses in a lot of cases). Well, at least me. :)I think it''s pretty reasonable for the providers to specify which platform they''re a default provider for; this will generally work pretty well, and in those cases where it does not and where there are multiple equally suitable confines, users can specify a default provider pretty easily: Package { provider => myprovider } It might be nice to have an ability to quickly compare package counts with different providers, but even that doesn''t really work everywhere -- blastwave on Solaris will show the same packages that Solaris itself shows, just as dpkg, apt, and aptitude will all show the same packages, so you can''t use package count to determine defaults. The real problem here is that I managed to screw up and ignore the ''defaultfort'' settings. As long as that''s fixed, it should all work pretty well. I don''t like the idea of using a Fact for this because you have to modify that central fact to add a new provider. In fact, one of my primary feature goals for providers was to get the choice-making out of the central code and into the edge, so that people could add new providers and have them used as the default automatically. There are still plenty of other package formats to support, I fear (although it does seem like we''re covering nearly all of them at the moment). Or am I missing something? -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
2006/9/8, Matthew Palmer <mpalmer@hezmatt.org>:> > On Fri, Sep 08, 2006 at 09:05:13PM +0200, José González Gómez wrote: > > 2006/9/8, Matthew Palmer <mpalmer@hezmatt.org>: > > > /me hides behind something Gentoo-fanatic proof > > > > mmmm... you were talking about me, weren''t you? :oP > > Not really -- you''re a Gentoo user, just like I''m a Debian/Ubuntu user. I > was thinking more of some of the real Gentoo fanboys I''ve met over the > years, who were just completely incapable of acknowledging that some of > Gentoo''s perceived advantages weren''t universally applicable.hmmm.... don''t know why you say Gentoo''s perceived advantages aren''t universally applicable. As an example of Gentoo''s unversal applicability, I installed Gentoo in my bread toster. Now my bread spends two hours insted of two minutes to get toasted, but man, I get it exactly the way I want it... I will publish the recipe soon... the puppet recipe, I mean. Best regards Jose _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
2006/9/9, Luke Kanies <luke@madstop.com>:> > On Sep 8, 2006, at 2:40 PM, Erik Hollensbe wrote: > > > > Maybe I deleted it before I posted it yesterday, but the YAML > > solution to facter that I was talking about the other day (where YAML > > can override facter facts) would solve this rather well, given a > > "packagemanager" fact of some sort. > > > > Those of us who use FreeBSD would be delighted to know that we could > > use RPM for linux-compat situations (as that''s what the linux-compat > > suite uses in a lot of cases). Well, at least me. :) > > I think it''s pretty reasonable for the providers to specify which > platform they''re a default provider for; this will generally work > pretty well, and in those cases where it does not and where there are > multiple equally suitable confines, users can specify a default > provider pretty easily: > > Package { provider => myprovider } > > It might be nice to have an ability to quickly compare package counts > with different providers, but even that doesn''t really work > everywhere -- blastwave on Solaris will show the same packages that > Solaris itself shows, just as dpkg, apt, and aptitude will all show > the same packages, so you can''t use package count to determine defaults. > > The real problem here is that I managed to screw up and ignore the > ''defaultfort'' settings. As long as that''s fixed, it should all work > pretty well.Did you take a look at the patch I uploaded? I hope it solves the problem: http://www.reductivelabs.com/cgi-bin/puppet.cgi/ticket/261 I don''t like the idea of using a Fact for this because you have to> modify that central fact to add a new provider. In fact, one of my > primary feature goals for providers was to get the choice-making out > of the central code and into the edge, so that people could add new > providers and have them used as the default automatically. There are > still plenty of other package formats to support, I fear (although it > does seem like we''re covering nearly all of them at the moment). > > Or am I missing something? >Well, I think the problem was puppet was selecting applicable providers based just in the existence of certain commands, and I think this isn''t enough, as previously discussed: I had rpm and dpkg installed in my systems because from time to time I inspect red hat or debian packages (I will deny this if you tell it at any Gentoo list :oP). The detection should be a bit more intelligent, maybe detecting the corresponding package database. Whether this should be discovered as a fact or included in the provider is another discussion. Best regards Jose _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Sat, 2006-09-09 at 10:20 -0700, Luke Kanies wrote:> I don''t like the idea of using a Fact for this because you have to > modify that central fact to add a new provider. In fact, one of my > primary feature goals for providers was to get the choice-making out > of the central code and into the edge, so that people could add new > providers and have them used as the default automatically. There are > still plenty of other package formats to support, I fear (although it > does seem like we''re covering nearly all of them at the moment). > > Or am I missing something?Not really, I was mainly talking about helping make decisions in the manifest with feature-based facts. I agree that adding a new provider should be as easy as possible, and not require lots of changes all over the place. The only rub is that what a provider checks to see if it''s applicable and similar checks in Facter will be identical; how hard/bad would it be to allow providers to add facts to Facter in a transparent way ? David
On Sep 12, 2006, at 4:20 AM, David Lutterkort wrote:> Not really, I was mainly talking about helping make decisions in the > manifest with feature-based facts. I agree that adding a new provider > should be as easy as possible, and not require lots of changes all > over > the place. > > The only rub is that what a provider checks to see if it''s applicable > and similar checks in Facter will be identical; how hard/bad would > it be > to allow providers to add facts to Facter in a transparent way ?Well, the basic suitability mechanism is the same between Facter and providers, but the criteria is usually going to be different. Most providers use binaries to determine suitability, while Facter doesn''t even support that. What facts would you like to see for providers? I can see wanting to make decisions based on the default provider for a given type, but not much else. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
Matthew Palmer wrote:> > I wonder if there should be a set of RedHatThis and RedHatThat facts for > this when OperatingSystem == ''RedHat''. There''s already the Architecture > fact (that''s quite Debian-specific at present), so we''ve got a precedent.Seems like there should be, because there are so many different definitions of "Red Hat". David, any recommendations?> The problem with trying to generalise the versioning info is that different > distros (and OSes) have different ideas for all this sort of thing, so there > won''t be a set of names that match perfectly for everyone. The only way out > of this, that I can see, is to strictly define what *we* mean by, for > example, "OperatingSystemRelease", and then try and shoehorn various > distributors'' ideas into that model.Yep. Unnecessary variety, but we have to deal with it anyway.>>> Using lsb_release -r for operatingsystemrelease and lsb_release -i for >>> operatingsystem should be OK for most Linux distributions. >> The problem with lsb_release is that it''s not always available. It''s >> not installed by default on Debian, for instance. > > <fx: Places Debian maintainer hat on, at a jaunty angle> > > A quick Depends: modification could make that problem go away, though.Then it seems like a good idea to add that to the Facter package. BTW, lsb_release -i on Fedora lists ''FedoraCore''; should I s/Core//?> I think some LSB facts wouldn''t go astray. Might also be handy for the four > people in the world who actually want to use the features of the LSB only to > stay distro-independent.Should they be named specially, or just use the same fact names but with lsb-supplied info? -- The one thing more difficult than following a regimen is not imposing it on others. -- Marcel Proust --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
David Lutterkort wrote:> > What does that mean for facter and the use of facts in manifests ? > Instead of having facter report the OS release, and then using rpm if > it''s a Red Hat OS, and apt if it''s a Debian based OS, we should try to > build a standard set of facts that tests features of the client and then > reports things like ''has_rpm'' and ''has_apt'' so that manifests can make > decisions without inferring properties from some other fact. Instead of > a bunch of boolean has_* facts, it might be more useful to split the > facts into pretty focused categories with a well-known set of values, > e.g. use a ''pkgformat'' fact with possible values ''rpm'' and ''apt'' (are > there others ? ;)Hmm. I hadn''t thought of this -- exposing in the manifest which providers are suitable. Certainly that should be possible -- Puppet already knows what providers are suitable for a given type. I think it should be something like ''features'' instead of ''facts'', though -- it''s too far away from Facter, and too tied to Puppet''s internals. The only question, then, is are there features we''ll be concerned about that won''t be modeled as providers? If not, then we''re golden; if so, this doesn''t really solve the problem.> That of course will only be useful if we can actually collect a pretty > broad set of features that people need to base their decisions on in > manifests, and add them to facter - send patches ;)Yeah, this is definitely one of the faults and benefits with the Puppet/Facter relationship -- your decision making is much less ad-hoc, but it also requires more effort to make a decision. Now that Puppet can automatically distribute facts for you, though, things should be quite a bit easier to set up. (Oops, just realized I never documented that...) -- The Ninety-Ninety Rule of Project Schedules: The first 90% of the task takes 90% of the time, and the last 10% takes the other 90%. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, Sep 14, 2006 at 03:44:49PM -0500, Luke Kanies wrote:> Matthew Palmer wrote: > BTW, lsb_release -i on Fedora lists ''FedoraCore''; should I s/Core//?I don''t think we should muck with what the distributor puts in their LSB info. If Fedora want to be known as FedoraCore to all LSB-using apps, that''s their call.> > I think some LSB facts wouldn''t go astray. Might also be handy for the four > > people in the world who actually want to use the features of the LSB only to > > stay distro-independent. > > Should they be named specially, or just use the same fact names but with > lsb-supplied info?Tricky. Perhaps stick with lsb_<foo> (or lsb<foo> if we''re not doing underscores in facts) at first, and then move the values across to the regular names if people are favouring the LSB facts over the adhoc ones. - Matt
> I totally agree with everything you said, BTW. Capabilities-based detection >> is far more useful than inferring everything from the identity of the >> system. We''ll have to be careful to avoid the recently reported problem >> of >> a Gentoo system detecting /usr/bin/rpm and getting a little assumptive, >> though.I think that''s kewl - have a "capabilities" list that can be matched against in puppet. However, most of our functions in cfengine still makes broad assumptions for "rhel4" (which includes RedHat and CentOS) which will be valid for a mast majority of cases (yum/rpm, 2.6 kernel, openldap 2.2, etc). So there should still be generic labels for operating system flavors. If "case"/binary-selectors/"if" supported wildmat/regex matches (i think highly useful), would propose : operatingsystem: "linux/centos", "linux/redhat", "linux/fedora", "linux/suse", or just "linux", "solaris", etc operatingsystemrelease: "4.1", "4.1ES", "5", "10", nil, or "unknown" RedHat Enterprise Linux 4 ES (update 2) = operatingsystem: linux/redhat operatingsystemrelease: 4.2ES Solaris 9 = operatingsystem: solaris operatingsystemrelease: 9 Generic_118558-17 Then i could say something like: case $operatingsystem { linux/[redhat|centos]: { case $operatingsystemrelease { 3*: { include rhel3 } 4*: { include rhel4 } } } linux*: { include linux } solaris: { case $operatingsystemrelease { 8*: { include solaris8 } 9*: { include solaris9 } 10*: { include solarisX } } } } else: operatingsystem: linux operatingsystemname: "redhat", "centos", "suse", or "linux" (unknown) operatingsystemrelease: "4", "4ES", "5", "10", nil, or "unknown" operatingsystempatchlevel: "0", "1", "4", nil RedHat Enterprise Linux 4 ES (update 2) = operatingsystem: linux operatingsystemname: redhat operatingsystemrelease: 4ES operatingsystempatchlevel: 2 Solaris 9 = operatingsystem: solaris operatingsystemname: sunos (or solaris) operatingsystemrelease: 9 operatingsystempatchlevel: Generic_118558-17 but "case" gets messier: case $operatingsystem { linux: { case $operatingsystemname: { redhat: { case $operatingsystemrelease: { 3ES: { include rhel3 } 3AS: { include rhel3 } 4ES: { include rhel4 } ... } centos: { case $operatingsystemrelease: { 3: { include rhel3 } 4: { include rhel4 } } } default: { include linux } } } solaris: case $operatingsystemrelease { 8: { include solaris8 } 9: { include solaris9 } 10: { include solarisX } } } For those who wanna know whether "apt" or "yum" is used for package updates, a capability array would come in handy, but would need a mechanism to search it. Is there harm in having "facts" defined which don''t apply to the underlying OS (as empty or nil) ? What''s the harm in having a few extra "facts" registered on one platform that are meaningless/empty but useful on another ? I''m far more interested on having easy-to-grok config files that do work rather than "clever" structures and templates - at least one positive aspect of cfengine. -ericb
On Thu, 2006-09-14 at 17:07 -0700, Eric Berggren wrote:> > I totally agree with everything you said, BTW. Capabilities-based detection > >> is far more useful than inferring everything from the identity of the > >> system. We''ll have to be careful to avoid the recently reported problem > >> of > >> a Gentoo system detecting /usr/bin/rpm and getting a little assumptive, > >> though. > > I think that''s kewl - have a "capabilities" list that can be matched > against in puppet. However, most of our functions in cfengine still > makes broad assumptions for "rhel4" (which includes RedHat and CentOS) > which will be valid for a mast majority of cases (yum/rpm, 2.6 kernel, > openldap 2.2, etc). So there should still be generic labels for > operating system flavors. > > If "case"/binary-selectors/"if" supported wildmat/regex matches (i think > highly useful), would propose : > > operatingsystem: "linux/centos", "linux/redhat", "linux/fedora", > "linux/suse", or just "linux", "solaris", etc > operatingsystemrelease: "4.1", "4.1ES", "5", "10", nil, or "unknown" > > RedHat Enterprise Linux 4 ES (update 2) => operatingsystem: linux/redhat > operatingsystemrelease: 4.2ES > > Solaris 9 => operatingsystem: solaris > operatingsystemrelease: 9 Generic_118558-17The problem with this is that it introduces a hierarchy of interrelated facts, which will be great for some uses, and not useful for others. I really think the only way we can help people write readable, portable manifests is by adding feature-based tests one-by-one to facter, where each feature gives a narrowly defined indication of something being available/behaving a certain way or not. And trying to deduce e.g. what the right package manager is solely based on a classification of something as broad as OS isn''t sufficient as the gentoo portage vs. rpm example shows. It''s stuff that necessarily belongs on the client.> For those who wanna know whether "apt" or "yum" is used for package > updates, a capability array would come in handy, but would need a > mechanism to search it.I think one fact per feature is the way to go here, and facter would also have to bear the burden of deciding which feature is really available if more than one seems to be around (like in the gentoo portage vs. rpm problem)> Is there harm in having "facts" defined which don''t apply to the > underlying OS (as empty or nil) ? What''s the harm in having a few extra > "facts" registered on one platform that are meaningless/empty but useful > on another ? > > I''m far more interested on having easy-to-grok config files that do work > rather than "clever" structures and templates - at least one positive > aspect of cfengine.Exactly, the work of figuring out what''s there or not should not be replicated in lots of manifests across the puppet user community; instead it should be centralized in one place, like facter. David
On Thu, 2006-09-14 at 15:57 -0500, Luke Kanies wrote:> David Lutterkort wrote: > > > > What does that mean for facter and the use of facts in manifests ? > > Instead of having facter report the OS release, and then using rpm if > > it''s a Red Hat OS, and apt if it''s a Debian based OS, we should try to > > build a standard set of facts that tests features of the client and then > > reports things like ''has_rpm'' and ''has_apt'' so that manifests can make > > decisions without inferring properties from some other fact. Instead of > > a bunch of boolean has_* facts, it might be more useful to split the > > facts into pretty focused categories with a well-known set of values, > > e.g. use a ''pkgformat'' fact with possible values ''rpm'' and ''apt'' (are > > there others ? ;) > > Hmm. I hadn''t thought of this -- exposing in the manifest which > providers are suitable. > > Certainly that should be possible -- Puppet already knows what providers > are suitable for a given type.The only thing I don''t see with this is how the flow would go: right now, providers do their tests on the _client_ after the manifest has been evaluated and sent to the client - wouldn''t those tests need to happen on the client before the manifest is evaluated and be sent to the server ? That''s why I suggested adding it to facter, since that''s where it needs to go in terms of flow. Whether the actual code lives in facter or puppet doesn''t matter too much to me.> I think it should be something like ''features'' instead of ''facts'', > though -- it''s too far away from Facter, and too tied to Puppet''s internals.Fair enough. As long as there is an easy way to get to a list of possible features (and what they mean) either keeping everything in facts or in features would work.> The only question, then, is are there features we''ll be concerned about > that won''t be modeled as providers? If not, then we''re golden; if so, > this doesn''t really solve the problem.It solves part of the problem, i.e. those where manifests and providers need to make decisions based on the same features; but what manifests want is probably a broader category than what providers need. That''s why I think using a mechanism that both providers and manifests can use is hte way to go.> > That of course will only be useful if we can actually collect a pretty > > broad set of features that people need to base their decisions on in > > manifests, and add them to facter - send patches ;) > > Yeah, this is definitely one of the faults and benefits with the > Puppet/Facter relationship -- your decision making is much less ad-hoc, > but it also requires more effort to make a decision. > > Now that Puppet can automatically distribute facts for you, though, > things should be quite a bit easier to set up. (Oops, just realized I > never documented that...)Yes, that would be a good way to tackle that - distributing facts as plugins from puppet. David
David Lutterkort wrote:> > The problem with this is that it introduces a hierarchy of interrelated > facts, which will be great for some uses, and not useful for others. I > really think the only way we can help people write readable, portable > manifests is by adding feature-based tests one-by-one to facter, where > each feature gives a narrowly defined indication of something being > available/behaving a certain way or not.I basically agree with this. I like simpler structures that the user can make complex if necessary.> And trying to deduce e.g. what the right package manager is solely based > on a classification of something as broad as OS isn''t sufficient as the > gentoo portage vs. rpm example shows. It''s stuff that necessarily > belongs on the client.Fortunately we have the defaults mechanism so whatever Puppet decides isn''t necessarily law.> I think one fact per feature is the way to go here, and facter would > also have to bear the burden of deciding which feature is really > available if more than one seems to be around (like in the gentoo > portage vs. rpm problem)I''d much rather havea ''feature'' function: if feature(rpm) { ... } -- This space intentionally has nothing but text explaining why this space has nothing but text explaining that this space would otherwise have been left blank, and would otherwise have been left blank. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
David Lutterkort wrote:> > The only thing I don''t see with this is how the flow would go: right > now, providers do their tests on the _client_ after the manifest has > been evaluated and sent to the client - wouldn''t those tests need to > happen on the client before the manifest is evaluated and be sent to the > server ? That''s why I suggested adding it to facter, since that''s where > it needs to go in terms of flow. Whether the actual code lives in facter > or puppet doesn''t matter too much to me.features = Hash.new { |hash, key| hash[key] = [] } Puppet::Type.eachtype.do |type| type.suitable.each do |provider| features[type.name] << provider.name end end Then just upload the features list with the fact list. There''s nothing about the providers that says when their suitability should be tested. Oh, and the ''feature'' function would need two arguments: if feature(package, rpm) { ... } Hackish, but true. Both users and groups have a ''netinfo'' provider.> It solves part of the problem, i.e. those where manifests and providers > need to make decisions based on the same features; but what manifests > want is probably a broader category than what providers need. That''s why > I think using a mechanism that both providers and manifests can use is > hte way to go.Okay, makes sense. Maybe a parallel fact database for just booleans (the Gentoo guys would *love* this), and each provider would be one of those booleans. You could define your own features, and Puppet would automatically add its features in before sending them up. -- Someday I want to be rich. Some people get so rich they lose all respect for humanity. That''s how rich I want to be. --Rita Rudner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Eric Berggren wrote:> > I think that''s kewl - have a "capabilities" list that can be matched > against in puppet. However, most of our functions in cfengine still > makes broad assumptions for "rhel4" (which includes RedHat and CentOS) > which will be valid for a mast majority of cases (yum/rpm, 2.6 kernel, > openldap 2.2, etc). So there should still be generic labels for > operating system flavors.I like the capabilities list, but I don''t want to build complicated facts. As long as all of the information you want is available, it''s easy enough to build complicated facts yourself.> For those who wanna know whether "apt" or "yum" is used for package > updates, a capability array would come in handy, but would need a > mechanism to search it.Yeah, there''s no external exposure of which providers work and which are the defaults. That should definitely be added.> Is there harm in having "facts" defined which don''t apply to the > underlying OS (as empty or nil) ? What''s the harm in having a few extra > "facts" registered on one platform that are meaningless/empty but useful > on another ?I don''t think there''s any harm at all.> I''m far more interested on having easy-to-grok config files that do work > rather than "clever" structures and templates - at least one positive > aspect of cfengine.Yep. -- To have a right to do a thing is not at all the same as to be right in doing it. -- G. K. Chesterton --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> > I think that''s kewl - have a "capabilities" list that can be matched > > against in puppet. However, most of our functions in cfengine still > > makes broad assumptions for "rhel4" (which includes RedHat and > > CentOS) > > which will be valid for a mast majority of cases (yum/rpm, 2.6 > > kernel, > > openldap 2.2, etc). So there should still be generic labels for > > operating system flavors.> The problem with this is that it introduces a hierarchy of interrelated > facts, which will be great for some uses, and not useful for others. I > really think the only way we can help people write readable, portable > manifests is by adding feature-based tests one-by-one to facter, where > each feature gives a narrowly defined indication of something being > available/behaving a certain way or not.Indeed, one can''t evaluate "$operatingsystemrelease" without "$operatingsystem" (name). This particular "factoid" is going to be so prevalent, seems like deserving of it''s own function within puppet: if os(rhel) && osver(3) { ... } (where osver(3) == osver(3ES) == osver(3.1AS) == (osver >= 3) )> I like the capabilities list, but I don''t want to build complicated > facts. As long as all of the information you want is available, it''s > easy enough to build complicated facts yourself.-> I''d much rather havea ''feature'' function: -> -> if feature(rpm) { ... } Yes and yes(!) Buut, it''s fair to say (i''m convinced) that a vast majority (+98%) of sites will be managing a standardized distribution of some sort (RedHat, SuSE, Solaris, Xenix(!) where assumptions can be relied upon regarding services and methods. Complexity arises from deviations and/or customizations (sure, there''s probably a few running Gentoo/RPM/apt) -- have a feature matrix available for those who foster such attrocities ;) but keep the common case simple and concise as well. ergo if $os == redhat && $osver == 4 { package { foo: provider => rpm, ensure => installed } } instead of encoding hierarchies of features (somewhere): if feature(rpm,bash,libc,local_disk,keyboard_attached,tubes_not_full) package { foo: ... } } One shouldn''t have to create complex facts either for such common things. Just be able to have a standard method of getting the os name and version that''s somewhat predictable across the field (earlier discussions of "operatingsystemrelease" being the kernel version on linux surrounded this consistency ''cause it was meanlingless here while useful for Solaris, etc) The feature matrix should be easily extended as well as the default set expanded over time. I really like this better than creating additional "facts" where it''s just a boolean value (ie, how we currently create "classes" in cfengine based on the result of a shell-script one-liner for testing complex/arbitrary attributed of the local system). -ericb
Matthew Palmer wrote:> > I don''t think we should muck with what the distributor puts in their LSB > info. If Fedora want to be known as FedoraCore to all LSB-using apps, > that''s their call.Ok.> Tricky. Perhaps stick with lsb_<foo> (or lsb<foo> if we''re not doing > underscores in facts) at first, and then move the values across to the > regular names if people are favouring the LSB facts over the adhoc ones.Sounds good. -- Hanlon''s razor: Never attribute to malice that which can adequately be explained by stupidity. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Eric Berggren wrote:> > Indeed, one can''t evaluate "$operatingsystemrelease" without > "$operatingsystem" (name). This particular "factoid" is going to be so > prevalent, seems like deserving of it''s own function within puppet: > > if os(rhel) && osver(3) { ... } > > (where osver(3) == osver(3ES) == osver(3.1AS) == (osver >= 3) )Hmm. I could actually pretty easily generate functions for every fact, so that this would work with every fact, although I''d agree that we''d probably want something shorter than ''operatingsystemrelease'' as a function name.> Buut, it''s fair to say (i''m convinced) that a vast majority (+98%) of > sites will be managing a standardized distribution of some sort (RedHat, > SuSE, Solaris, Xenix(!) where assumptions can be relied upon regarding > services and methods. Complexity arises from deviations and/or > customizations (sure, there''s probably a few running Gentoo/RPM/apt) -- > have a feature matrix available for those who foster such attrocities ;) > but keep the common case simple and concise as well.One problem is that most people run more than one OS, so they''re generally running multiple "standard" distributions and they need their tools to deal with the differences.> ergo > if $os == redhat && $osver == 4 { > package { foo: provider => rpm, ensure => installed } > } > > instead of encoding hierarchies of features (somewhere): > > if feature(rpm,bash,libc,local_disk,keyboard_attached,tubes_not_full) > package { foo: ... } > }I more meant that rather than Puppet or Facter internally building complicated facts (like $platform == "$os-$osrel") or features, it could be done by the user in a relatively custom way. It''s probably not a bad idea to have some standard composite facts, like the fqdn fact recently submitted by Jeff McCune.> One shouldn''t have to create complex facts either for such common > things. Just be able to have a standard method of getting the os name > and version that''s somewhat predictable across the field (earlier > discussions of "operatingsystemrelease" being the kernel version on > linux surrounded this consistency ''cause it was meanlingless here while > useful for Solaris, etc)I agree with the original poster, though, that we should discourage using this information in distributable code. Do whatever you want with your own stuff, but as people start to distribute Puppet code, it''s going to be important that the code tests features, not just platforms.> The feature matrix should be easily extended as well as the default set > expanded over time. I really like this better than creating additional > "facts" where it''s just a boolean value (ie, how we currently create > "classes" in cfengine based on the result of a shell-script one-liner > for testing complex/arbitrary attributed of the local system).Well, one big difference between cfengine booleans and Puppet features would be that our features would be tested by feature providers, which can be quite a bit more complicated than simply testing if a file exists. -- Hanlon''s razor: Never attribute to malice that which can adequately be explained by stupidity. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
>> Indeed, one can''t evaluate "$operatingsystemrelease" without >> > "$operatingsystem" (name). This particular "factoid" is going to be so >> > prevalent, seems like deserving of it''s own function within puppet: >> > >> > if os(rhel) && osver(3) { ... } >> > >> > (where osver(3) == osver(3ES) == osver(3.1AS) == (osver >= 3) )> Hmm. I could actually pretty easily generate functions for every fact, > so that this would work with every fact, although I''d agree that we''d > probably want something shorter than ''operatingsystemrelease'' as a > function name.It''ll be common enough in virtually any heterogenous environment.> One problem is that most people run more than one OS, so they''re > generally running multiple "standard" distributions and they need their > tools to deal with the differences.>> > ergo >> > if $os == redhat && $osver == 4 { >> > package { foo: provider => rpm, ensure => installed } >> > } >> > >> > instead of encoding hierarchies of features (somewhere): >> > >> > iffeature(rpm,bash,libc,local_disk,keyboard_attached,tubes_not_full)>> > package { foo: ... } >> > }> I more meant that rather than Puppet or Facter internally building > complicated facts (like $platform == "$os-$osrel") or features, it could > be done by the user in a relatively custom way. It''s probably not a bad > idea to have some standard composite facts, like the fqdn fact recently > submitted by Jeff McCune.> I agree with the original poster, though, that we should discourage > using this information in distributable code. Do whatever you want with > your own stuff, but as people start to distribute Puppet code, it''s > going to be important that the code tests features, not just platforms.I too complete agree -- particularly for this case (selecting actions based on operating system). My rough examples were using the current available scheme for OS selection... Since most sites will need to do this anyway in some form, why not provide a defined method built within puppet for selecting among the common platforms in addition to having the set of features/capabilities for finer-grained detail for those that need it ? But I''m still certain most folks will be making decisions for actions based on "rhel4" or "solaris9" rather than individual "has_rpm" or "bsd_style_ps" type checks. -ericb -- Occam''s razor: entities should not be multiplied beyond necessity.
Eric Berggren wrote:> > Since most sites will need to do this anyway in some form, why not > provide a defined method built within puppet for selecting among the > common platforms in addition to having the set of features/capabilities > for finer-grained detail for those that need it ?You mean just a ''platform'' boolean function or something? if platform(rhel4) { ... } That kind of thing?> But I''m still certain most folks will be making decisions for actions > based on "rhel4" or "solaris9" rather than individual "has_rpm" or > "bsd_style_ps" type checks.I know that''s what people will start with, but as much as possible we want to encourage feature-based decisions. I think over time it will become more natural to think about features than about platforms, and the more we can encourage it the better off we''ll be. -- I object to doing things that computers can do. --Olin Shivers --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Sep 28, 2006, at 12:52 PM, Luke Kanies wrote:> Eric Berggren wrote: >> >> Since most sites will need to do this anyway in some form, why not >> provide a defined method built within puppet for selecting among the >> common platforms in addition to having the set of features/ >> capabilities >> for finer-grained detail for those that need it ? > > You mean just a ''platform'' boolean function or something? > > if platform(rhel4) { ... } > > That kind of thing? > >> But I''m still certain most folks will be making decisions for actions >> based on "rhel4" or "solaris9" rather than individual "has_rpm" or >> "bsd_style_ps" type checks. > > I know that''s what people will start with, but as much as possible we > want to encourage feature-based decisions. I think over time it will > become more natural to think about features than about platforms, and > the more we can encourage it the better off we''ll be.I agree wholeheartedly with that. How much are those goals stressed in the documentation? Such intricacies aren''t obvious to every administrator (I can rattle off a few…) so maybe a gently preachy but highly visible document is in order, maybe something that will summarize in a sort-of dental hygienist way what pitfalls and bad habits the software is designed (at least in part) to help administrators avoid. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Benjamin C. Kite wrote:> > I agree wholeheartedly with that. How much are those goals stressed in > the documentation? > > Such intricacies aren''t obvious to every administrator (I can rattle off > a few…) so maybe a gently preachy but highly visible document is in > order, maybe something that will summarize in a sort-of dental hygienist > way what pitfalls and bad habits the software is designed (at least in > part) to help administrators avoid.I agree, such a document would be a good idea. -- Always be wary of any helpful item that weighs less than its operating manual. -- Terry Pratchett --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com