Hi John,
Thanks for taking the time to respond :) Replies inline.
On Mar 20, 2013, at 8:01 AM, jcbollinger <john.bollin...@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+unsubscr...@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+unsubscr...@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.
