Puppet users - Mar 2013 - LSB Fact resolution in the absence of -lsb package

Hi there,

in house, we rely on the lsb facts:
lsbdistcodename, lsbdistdescription, lsbdistid, lsbdistrelease, and
lsbmajdistrelease

all of which are essentially derived from the
/etc/${distro-specific-release-file} and don''t _really_ need the lsb
packages (and the associated bloat) installed.

I''d like to come up with a good way to allow these facts to exist while
streamlining our systems.
I see a few different approaches, and thought Id ask for community input on the
best solution before just picking a direction and running with it.


1) some idea I''ve not thought up. (I''m sure there''s a
few of them)



2) distribute a script to derive this info. /opt/puppet/bin/lsb_release_lite or
something, and in the absence of lsb_release (the binary that facter turns to to
generate this information) facter asks this script.

PRO: Minimal changes to existing facts.
PRO: Adds "robustness" while keeping the os-specific code out of the
facts.

CON: Another script to maintain in puppet.
CON: can''t override what lsb_release provides on edge OSes with funky
lsb vaues

2A) distribute as part of PE/Puppet:
  PRO: More immediately available sexy.
  CON: More stuff distributed as part of PE/Puppet.

2B) distribute as supplementary module on forge:
 PRO: Outside of puppet.  / product distance / resisting scope creep.
 CON: Lack of visibility/awareness/immediately available sexy.



3) adjust the facts to derive the data in the absence of the binary.

PRO: Additional "robustness".

CON: moar bugs in facter! more complicated facts which could slow execution time
(minimally) if not written properly.
CON: can''t override what lsb_release provides on edge OSes with funky
lsb vaues



4) distribute additional facts (negatively weighted) to provide this information
in the absence of the binary.

PRO: Everything is derived from facts, as opposed to an external script.
PRO: Have a means to override funky edge OSes if desired.

CON: The worst parts of 3, with additional confusion.

4A )  distribute them in facter core
  PRO: More immediately available sexy..
  CON: Where does ''core'' end?

4B) distribute as forge module
  PRO: not part of core.
  CON: not part of core.


thoughts?

________________________________

This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Tuesday, March 19, 2013 2:27:22 PM UTC-5, Wolf Noble
wrote:
>
> Hi there, 
>
> in house, we rely on the lsb facts: 
> lsbdistcodename, lsbdistdescription, lsbdistid, lsbdistrelease, and 
> lsbmajdistrelease 
>
> all of which are essentially derived from the 
> /etc/${distro-specific-release-file} and don''t _really_ need the
lsb
> packages (and the associated bloat) installed. 
>

Well, that''s a matter of interpretation.  The lsb packages typically
ensure
that the system has all the pieces required for compliance with the LSB 
specifications, and the facts describe details of the compliance, such as 
which version of LSB the system complies with.  If your systems are not, in 
fact, fully LSB-compliant, then it is of questionable wisdom to suggest 
otherwise to Puppet.
 
>
> I''d like to come up with a good way to allow these facts to exist
while
> streamlining our systems. 
> I see a few different approaches, and thought Id ask for community input 
> on the best solution before just picking a direction and running with it. 
>
>
If you do not want to require your systems to be fully LSB-compliant, then 
your Puppet manifests should not rely on LSB-associated facts.  If, on the 
other hand, you need to rely on LSB facts, then you should ensure your 
systems LSB-compliant.  Certainly if you rely on third-party modules that 
in turn require LSB-associated facts for correct operation then you have to 
assume that your nodes must be LSB-compliant.


John


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Hi John,

Thanks for taking the time to respond :) Replies inline.

On Mar 20, 2013, at 8:01 AM, jcbollinger <John.Bollinger@stJude.org>
 wrote:
> On Tuesday, March 19, 2013 2:27:22 PM UTC-5, Wolf Noble wrote:
> Hi there,
>
> in house, we rely on the lsb facts:
> lsbdistcodename, lsbdistdescription, lsbdistid, lsbdistrelease, and
lsbmajdistrelease
>
> all of which are essentially derived from the
/etc/${distro-specific-release-file} and don''t _really_ need the lsb
packages (and the associated bloat) installed.
>
>
> Well, that''s a matter of interpretation.  The lsb packages
typically ensure that the system has all the pieces required for compliance with
the LSB specifications, and the facts describe details of the compliance, such
as which version of LSB the system complies with.  If your systems are not, in
fact, fully LSB-compliant, then it is of questionable wisdom to suggest
otherwise to Puppet.
the lsbrelease fact certainly lists what parts of the LSB spec and additional
lsb modules the node is compliant with. I am not suggesting altering the output
of that.

The remainder of the facts seem to consistently correlate with pieces from the
distro specific release file. I''ve not found a node which does not
(although one may exist).
Looking at the lsb_release script, I see it referencing /etc/lsb-release and
/etc/[distro]-release and returning what it finds.
This enhancement didn''t seem too far out of line with what''s
going on behind the scenes in the first place.


> I''d like to come up with a good way to allow these facts to exist
while streamlining our systems.
> I see a few different approaches, and thought Id ask for community input on
the best solution before just picking a direction and running with it.
>
>
> If you do not want to require your systems to be fully LSB-compliant, then
your Puppet manifests should not rely on LSB-associated facts.  If, on the other
hand, you need to rely on LSB facts, then you should ensure your systems
LSB-compliant.  Certainly if you rely on third-party modules that in turn
require LSB-associated facts for correct operation then you have to assume that
your nodes must be LSB-compliant.
Well, the motivation behind this is easy collaboration. All my modules really
care about is lsbmajdistrelease and lsbdistid/osfamily/operatingsystem.
Stepping back a bit though, the underlying question is what''s the best
way to determine what major version of the OS is running.

lsbmajdistrelease is currently part of core, and one could expect it to exist on
any (linux) node that has puppet installed, unlike a custom site-specific fact
which would work fine for us, but not so well collaboratively.

Expanding the listed lsb facts'' functionality to provide the
information that can be derived in the absence of the lsb_release script
doesn''t seem like an overstep to me, but I''m happy to concede
that there may be a better direction to go. I''d be equally satisfied
(maybe even slightly happier) if operatingsystemmajrelease was added to current
facter to accompany operatingsystemrelease.

I felt that suggestion might be met with greater resistance, and then
there''s the same problem that depending on osfamily can bring for
earlier versions, although that problem is becoming less and less of a concern.


I don''t want to resort to a regex every time I looked to see what major
version of $os I''m on. That doesn''t seem the most efficient
way to go.
I want to remove the requirement for the lsb packages, as that is meeting with
some understandable resistance.

I''m not opposed to refactoring to include a not-yet-existent
operatingsystemmajrelease fact. I want to solve this in a fashion that is …
least likely to bite me or someone else later. :)

Do you still feel expanding lsbdistcodename lsbdistdescription lsbdistid
lsbdistrelease and lsbmajdistrelease (and not touching lsbrelease) is more
likely to lead to problems?

What would you suggest as an alternative?

>
> John
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

________________________________

This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, March 20, 2013 12:07:22 PM UTC-5, Wolf Noble
wrote:
>
>
> Well, the motivation behind this is easy collaboration. All my modules 
> really care about is lsbmajdistrelease and 
> lsbdistid/osfamily/operatingsystem. 
> Stepping back a bit though, the underlying question is what''s the
best way
> to determine what major version of the OS is running. 
>
> lsbmajdistrelease is currently part of core, and one could expect it to 
> exist on any (linux) node that has puppet installed, unlike a custom 
> site-specific fact which would work fine for us, but not so well 
> collaboratively. 
>
> Expanding the listed lsb facts'' functionality to provide the
information
> that can be derived in the absence of the lsb_release script
doesn''t seem
> like an overstep to me, but I''m happy to concede that there may be
a better
> direction to go. I''d be equally satisfied (maybe even slightly
happier) if
> operatingsystemmajrelease was added to current facter to accompany 
> operatingsystemrelease. 
>
>
For data that are derived from facts that are already presented to Puppet, 
you can easily create pseudo-facts such as you describe.  For example, put 
this in your site.pp, outside and before any node blocks:

$os_release_parts = split($operatingsystemrelease, ''[.]'')
$operatingsystemmajrelease = $os_release_parts[0]

Then use $::operatingsystemmajrelease anywhere in any of your manifests, or 
even in hiera, as if it were a client-provided fact.



John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.