[PATCH 1/1] Fixed #1628 - Changed node search to use certname rather than Facter hostname
James Turnbull
Signed-off-by: James Turnbull <ja...@lovedthanlost.net>
---
CHANGELOG | 2 ++
bin/puppet | 3 +--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/CHANGELOG b/CHANGELOG
index c54a852..1631700 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,4 +1,6 @@
0.24.x
+ Fixed #1628 - Changed node search to use certname rather than Facter hostname
+
Updated puppet binary documentation
Feature #1624 - Added RBAC roles to solaris user provider
diff --git a/bin/puppet b/bin/puppet
index 142ddd9..b54a5b7 100755
--- a/bin/puppet
+++ b/bin/puppet
@@ -184,10 +184,9 @@ end
# Collect our facts.
facts = Puppet::Node::Facts.find("me")
-facts.name = facts.values["hostname"]
# Find our Node
-node = Puppet::Node.find(facts.name)
+node = Puppet::Node.find(Puppet[:certname])
# Merge in the facts.
node.merge(facts.values)
--
1.5.5.1
Luke Kanies
it to my repo? It doesn't seem to be a valid patch that I can just
apply directly with 'patch', git am pukes on it, and i don't know
anything else.
I'd like to directly test this without rewriting it, but I have no
idea how, which is ridiculous.
Anyway...
I'd change Facts.find("me") to Facts.find(Puppet[:certname]), just for
consistency. It doesn't matter functionally, but it sure makes for
easier reading.
>
> # Find our Node
> -node = Puppet::Node.find(facts.name)
> +node = Puppet::Node.find(Puppet[:certname])
I'd also add an exception here if there's no node found; something like:
unless node = Puppet::Node.find...
raise "Could not find node %s" % Puppet[:certname]
end
That was my real problem -- not just that it wasn't looking for the
right node, but that when it didn't find it, it failed with:
/Users/luke/puppet/bin/puppet:193: undefined method `merge' for
nil:NilClass (NoMethodError)
>
> # Merge in the facts.
> node.merge(facts.values)
Awesome, thanks for knocking this out.
--
I object to doing things that computers can do. --Olin Shivers
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Todd Zullinger
> Can someone please explain to me hth I can take this email and apply
> it to my repo? It doesn't seem to be a valid patch that I can just
> apply directly with 'patch', git am pukes on it, and i don't know
> anything else.
>
> I'd like to directly test this without rewriting it, but I have no
> idea how, which is ridiculous.
[Disclaimer: I'm sure there are far more knowledgeable git folks than
I.]
The -3 option to git am can help out here. I've got a puppet clone
of the official master with remotes for both you and James. Here's
the steps I took to apply this patch:
# Save the mail, headers and all (you know this, but I mention it for
# posterity and completeness :).
# Update my puppet clone
$ git pull
$ git fetch lak
$ git fetch turnbull # (and curse github for being slow at the moment)
# Checkout 0.24.x branch from lak
$ git co lak/0.24.x
# Attempt to apply the patch
$ git am -3 /path/to/patch
Applying: Fixed #1628 - Changed node search to use certname rather than Facter hostname
error: patch failed: CHANGELOG:1
error: CHANGELOG: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged CHANGELOG
CONFLICT (content): Merge conflict in CHANGELOG
Auto-merged bin/puppet
Failed to merge in the changes.
Patch failed at 0001.
When you have resolved this problem run "git am -3 --resolved".
If you would prefer to skip this patch, instead run "git am -3 --skip".
To restore the original branch and stop patching run "git am -3 --abort".
# More cursing and grumbling about damn CHANGELOG files making life
# harder for little gain...
# ... deep breath, repeating "Serenity now!"
# Check the status, noting that CHANGELOG is unmerged
$ git st
CHANGELOG: needs merge
# Not currently on any branch.
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: bin/puppet
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# unmerged: CHANGELOG
#
# Edit CHANGELOG to fix up the conflicts and then add it to the index
$ git add CHANGELOG
# Tell git am the problems were resolved
$ git am --resolved
Applying: Fixed #1628 - Changed node search to use certname rather than Facter hostname
Another helpful technique is using the --reject option to git apply.
That will leave the parts of the patch that don't apply cleanly in
.rej files, as patch does. Then you can manually fix things up and
commit.
[I don't know if your experience is different, but my (admittedly
rather limited) experience is that ChangeLog files tend to cause this
kind of spurious patch application failure far more often than many
other changes do. So I tend to like the idea of not having them
around and instead generating them when building a tarball, from the
commit logs. Anyone working with a git repo can use git log to see
the changes already, and those getting a tarball can read the
generated ChangeLog file. But that's tangential to resolving the
conflicts when they occur, since they will inevitably occur from other
changes as well.]
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Religion. A daughter of Hope and Fear, explaining to Ignorance the
nature of the Unknowable.
-- Ambrose Bierce, The Enlarged Devil's Dictionary, 1906
Luke Kanies
> Luke Kanies wrote:
>> Can someone please explain to me hth I can take this email and apply
>> it to my repo? It doesn't seem to be a valid patch that I can just
>> apply directly with 'patch', git am pukes on it, and i don't know
>> anything else.
>>
>> I'd like to directly test this without rewriting it, but I have no
>> idea how, which is ridiculous.
>
> [Disclaimer: I'm sure there are far more knowledgeable git folks than
> I.]
>
> The -3 option to git am can help out here. I've got a puppet clone
> of the official master with remotes for both you and James. Here's
> the steps I took to apply this patch:
[Explanation of using 3-way merging]
Ah, that works; thanks.
>
> Another helpful technique is using the --reject option to git apply.
> That will leave the parts of the patch that don't apply cleanly in
> .rej files, as patch does. Then you can manually fix things up and
> commit.
I never have bothered to figure out how to use those .rej files. :/
>
> [I don't know if your experience is different, but my (admittedly
> rather limited) experience is that ChangeLog files tend to cause this
> kind of spurious patch application failure far more often than many
> other changes do. So I tend to like the idea of not having them
> around and instead generating them when building a tarball, from the
> commit logs. Anyone working with a git repo can use git log to see
> the changes already, and those getting a tarball can read the
> generated ChangeLog file. But that's tangential to resolving the
> conflicts when they occur, since they will inevitably occur from other
> changes as well.]
We're certainly getting merge conflicts on CHANGELOG all the damn time.
I'm amenable to at least investigating what it would take to directly
use the commit logs as the changelog,
although we'd definitely need some way to correctly associate commits
and tags -- I think it's critical that the changelog
show which commits are in which release. Any idea how to do that?
--
Charm is a way of getting the answer yes without asking a clear
question. -- Albert Camus
Todd Zullinger
> [Explanation of using 3-way merging]
>
> Ah, that works; thanks.
Glad it helped. It's nothing compared to the thanks I owe you for
puppet. :)
>> Another helpful technique is using the --reject option to git apply.
>> That will leave the parts of the patch that don't apply cleanly in
>> .rej files, as patch does. Then you can manually fix things up and
>> commit.
>
> I never have bothered to figure out how to use those .rej files. :/
I don't do much other than manually inserting the failed hunks from
them to the right place. If there's a better way to do it, I don't
know it and generally I hope to avoid needing to know.
> We're certainly getting merge conflicts on CHANGELOG all the damn
> time.
>
> I'm amenable to at least investigating what it would take to
> directly use the commit logs as the changelog, although we'd
> definitely need some way to correctly associate commits and tags --
> I think it's critical that the changelog show which commits are in
> which release. Any idea how to do that?
I'm not so hot with ruby and Rakefiles, nor with what the release
procedure is for puppet, so unfortunately, I don't have ideas in patch
form. But here are a few random thoughts.
Say we update CHANGELOG only at release time, then the previous
release tag would be in the first line and could be used. Some
pseudo/sh code as an example:
# somewhere in the bowels of the puppet release process...
# ...in a galaxy far, far away...
#
# have this passed in to the Rakefile or pulled from a version string
# in the source somewhere?
cur_rel=0.24.6
prev_rel=$(head -1 CHANGELOG)
# update the CHANGELOG
echo $cur_rel> CHANGELOG.tmp
git log --pretty=format:' %s%n' $prev_rel..$cur_rel>> CHANGELOG.tmp
echo "">> CHANGELOG.tmp
cat CHANGELOG>> CHANGELOG.tmp
mv CHANGELOG.tmp CHANGELOG
Now, the git log example there uses %s, which is only the summary, not
the full commit message. There is a %b format option for the body, if
the full message is desired in the CHANGELOG. That includes the
Signed-off-by: line as well. I'm not sure how much information you
want in the CHANGELOG or how attached to the current format you might
be. If you don't mind it changing, "git log $prev_rel..$cur_rel"
output could perhaps be used, or something in between that and just
the summary.
Another option is to have a Release-Notes-$version file that gets
update for each release with the important user visible changes (just
the things an end user would need to know when updating). Then, we
could just use "git log $tag > CHANGELOG" to give the gory details of
everything in the tree up to that point for those who want to know and
don't already have a git clone at hand. This lists commits that are
in that tag or the tag's ancestors.
FWIW, the git project does just the RelNotes part and omits the
ChangeLog file entirely. GNU coreutils (among others) uses a script
to convert git logs to GNU ChangeLog files. That script¹ and some of
the Makefile logic could be a nice place to look for ideas.
I'm sure some of this sounds like a pain, but I would hope that
setting it up would be a one time thing and could then alleviate the
constant pain of CHANGELOG conflicts. :)
¹ http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/gitlog-to-changelog;hb=HEAD
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Never do today that which will become someone else's responsibility
tomorrow.
Luke Kanies
This all sounds pretty good.
I think having just the summary in the CHANGELOG would be fine, and
having some kind of per-release release notes file would also be
pretty good. I think the release notes file would still need to be
maintained manually, wouldn't it? Unless maybe you include a keyword
in each commit that should go in the release notes; that should
actually work.
Can you open a 'refactor' ticket with this information?
--
The only really good place to buy lumber is at a store where the lumber
has already been cut and attached together in the form of furniture,
finished, and put inside boxes. --Dave Barry
Todd Zullinger
> I think having just the summary in the CHANGELOG would be fine, and
> having some kind of per-release release notes file would also be
> pretty good. I think the release notes file would still need to be
> maintained manually, wouldn't it? Unless maybe you include a
> keyword in each commit that should go in the release notes; that
> should actually work.
I suppose either way could work. I would suspect that a Release Notes
file wouldn't need to be updated all that frequently so it likely
wouldn't cause enough conflicts to be a real pain in the ass even if
it was maintained manually. It might even be easiest to look back
over the git log when a release is approaching and update the release
notes at that point.
> Can you open a 'refactor' ticket with this information?
Sure: http://projects.reductivelabs.com/issues/show/1638
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Everyone needs to believe in something. I believe I'll have another
beer.
James Turnbull
Hash: SHA1
Todd Zullinger wrote:
> Luke Kanies wrote:
>> I think having just the summary in the CHANGELOG would be fine, and
>> having some kind of per-release release notes file would also be
>> pretty good. I think the release notes file would still need to be
>> maintained manually, wouldn't it? Unless maybe you include a
>> keyword in each commit that should go in the release notes; that
>> should actually work.
>
> I suppose either way could work. I would suspect that a Release Notes
> file wouldn't need to be updated all that frequently so it likely
> wouldn't cause enough conflicts to be a real pain in the ass even if
> it was maintained manually. It might even be easiest to look back
> over the git log when a release is approaching and update the release
> notes at that point.
I already do this at:
http://reductivelabs.com/trac/puppet/wiki/UPGRADE
Not wedded to title, name, style, etc. Feel free to comment.
Regards
James
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI7ANk9hTGvAxC30ARAp5tAKDPnuGtoMKz7YGsylPbXDQyi0isVgCfQZNw
E+5BRVJOALP+rBsTAs33X5k=
=LJ6K
-----END PGP SIGNATURE-----