headers
James Turnbull | 1 Jan 2011 01:54

[Puppet Users] ANNOUNCE: Puppet Module Tool version 0.3.2

Hi all

We've just released version 0.3.2 of the puppet-module tool used to
create and retrieve modules from the Puppet Labs Forge.

You can update using Ruby gems:

$ gem install puppet-module

The major change in version 0.3.2 is a fix to the creation of module
metadata.  Until now modules created with the puppet-module tool did not
get properly populated metadata.json files.  This meant they did not
load properly in Puppet 2.6.x and later versions.

This is also related to a Puppet bug -
https://projects.puppetlabs.com/issues/4142 - which we'll be addressing
in Puppet 2.6.5 that incorrectly makes some metadata mandatory when a
metadata.json file is present.

We've also gone through the existing modules on the Forge and updated
their metadata.json files to ensure they have suitable metadata.

Regards

James Turnbull

--

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Barrett | 1 Jan 2011 08:57
Gravatar

Re: [Puppet Users] Re: Puppet & Hudson CI

On Thu, 30 Dec 2010, Stefan Schlesinger wrote:
> Would it be better to be able to have checkout a specific revision, or
> should I rather add support for checking out a tagged version?

Both are useful.  Some people might find it more convenient to switch
from one tag to another, while other people might find it more
convenient to time travel within the history of a single branch; the
time travelers might occasionally want to switch from one branch to
another.

--apb (Alan Barrett)

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 0 comments |
headers
Alan Barrett | 1 Jan 2011 09:04
Gravatar

Re: [Puppet Users] Documentation of report formats

On Thu, 30 Dec 2010, Paul Berry wrote:
> Those of you reading puppet-dev may have already noticed that we're making
> we've documented the changes we're anticipating here:
> http://projects.puppetlabs.com/projects/puppet/wiki/Report_Format_2

Is there improved support for noop mode?  I didn't notice anything like
status = "out of sync, but did not change due to noop mode".

--apb (Alan Barrett)

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 3 comments |
headers
bowlby | 1 Jan 2011 09:53
Picon

[Puppet Users] slave-facts on puppetmaster

Hi,

I'm figuring out a way to build a ssh-gateway. For that to work I want
access to the internal ipaddresses that are used by my slaves (which
get assigned by dhcp and thus are not predictable). This way I can
change the host-file on my ssh-gateway so that hostnames point to the
right nodes.

So I want something like:

SSH-gateway-hostfile:
192.168.1.12    hostname1
192.168.1.67    hostname2

Is there a way to access facts on from nodes other than the node
you're working on?

Thanks!

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 9 comments |
headers
Patrick | 1 Jan 2011 11:21
Picon

Re: [Puppet Users] slave-facts on puppetmaster


On Jan 1, 2011, at 12:53 AM, bowlby wrote:

> Hi,
> 
> I'm figuring out a way to build a ssh-gateway. For that to work I want
> access to the internal ipaddresses that are used by my slaves (which
> get assigned by dhcp and thus are not predictable). This way I can
> change the host-file on my ssh-gateway so that hostnames point to the
> right nodes.
> 
> So I want something like:
> 
> SSH-gateway-hostfile:
> 192.168.1.12    hostname1
> 192.168.1.67    hostname2
> 
> Is there a way to access facts on from nodes other than the node
> you're working on?

I think you could do this with storedconfigs+puppet_concat.  The idea is that you make the file fragments
using storedconfigs and then put the pieces together using puppet_concat.  This solution tries to get
around your original question.

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Turnbull | 1 Jan 2011 18:14

Re: [Puppet Users] Documentation of report formats

Alan Barrett wrote:
> On Thu, 30 Dec 2010, Paul Berry wrote:
>> Those of you reading puppet-dev may have already noticed that we're making
>> we've documented the changes we're anticipating here:
>> http://projects.puppetlabs.com/projects/puppet/wiki/Report_Format_2
> 
> Is there improved support for noop mode?  I didn't notice anything like
> status = "out of sync, but did not change due to noop mode".
> 
> --apb (Alan Barrett)
> 

Alan

If there isn't could you please log a ticket?

Thanks

James Turnbull

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Schulte | 1 Jan 2011 18:48

Re: [Puppet Users] slave-facts on puppetmaster

On Sat, Jan 01, 2011 at 12:53:11AM -0800, bowlby wrote:
> Hi,
> 
> I'm figuring out a way to build a ssh-gateway. For that to work I want
> access to the internal ipaddresses that are used by my slaves (which
> get assigned by dhcp and thus are not predictable). This way I can
> change the host-file on my ssh-gateway so that hostnames point to the
> right nodes.
> 
> So I want something like:
> 
> SSH-gateway-hostfile:
> 192.168.1.12    hostname1
> 192.168.1.67    hostname2
> 
> Is there a way to access facts on from nodes other than the node
> you're working on?
> 

Have a look at exported resources [1]. All your nodes that need an entry
can export a resource

 <at>  <at> host { $fqdn:
  ip           => $ipaddress,
  host_aliases => $hostname,
  ensure       => present,
  target       => '/ssh_gateway_hostfile',
  tag          => 'ssh-gateway',
}
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bram Enning | 3 Jan 2011 09:38
Picon

Re: [Puppet Users] slave-facts on puppetmaster

Thanks! Stefans suggestion seemed elegant and productive, and proved to be so.

On Sat, Jan 1, 2011 at 6:48 PM, Stefan Schulte
<stefan.schulte <at> taunusstein.net> wrote:
> On Sat, Jan 01, 2011 at 12:53:11AM -0800, bowlby wrote:
>> Hi,
>>
>> I'm figuring out a way to build a ssh-gateway. For that to work I want
>> access to the internal ipaddresses that are used by my slaves (which
>> get assigned by dhcp and thus are not predictable). This way I can
>> change the host-file on my ssh-gateway so that hostnames point to the
>> right nodes.
>>
>> So I want something like:
>>
>> SSH-gateway-hostfile:
>> 192.168.1.12    hostname1
>> 192.168.1.67    hostname2
>>
>> Is there a way to access facts on from nodes other than the node
>> you're working on?
>>
>
> Have a look at exported resources [1]. All your nodes that need an entry
> can export a resource
>
>  <at>  <at> host { $fqdn:
>  ip           => $ipaddress,
>  host_aliases => $hostname,
>  ensure       => present,
(Continue reading)

Permalink | Reply | 4 comments |
headers
jcbollinger | 3 Jan 2011 15:45

[Puppet Users] Re: Namespacing, includes and module lookup. Bug?


On Dec 24 2010, 6:10 am, Dan Carley <dan.car... <at> gmail.com> wrote:
[...]
> There are some hack-ish ways to work around it. You can specify that all of
> your includes come from the top scope by prefixing them with ::, such as
> 'include ::mysql'. But this makes for some pretty long winded manifest
> writing if you want to be sure 100% of the time. There isn't
> an equivalent syntax for require meta-parameters. You can achieve
> something vaguely similar with 'require ::mysql' which will create
> dependencies from all resources in the current class. It's certainly not the
> same effect though.

I would expect class name resolution to work the same way everywhere,
so if

notify { "foo':
    require => Class["::bar"]
}

does not work then I would account it a bug.  If it fails with an
error then fixing it can't break any manifests.

John

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
(Continue reading)

Permalink | Reply | 0 comments |
headers
jcbollinger | 3 Jan 2011 16:40

[Puppet Users] Re: Namespacing, includes and module lookup. Bug?


On Dec 24 2010, 8:41 am, Daniel Piddock <dgp-g... <at> corefiling.co.uk>
wrote:
> I've done a bit of poking around the issue tracker. Issue 4473
> http://projects.puppetlabs.com/issues/4473 appears to be the ticket
> related to this.

No, I don't think it is.  Issue 4473 is about resolving parent class
names in a class inheritance scenario.  Puppet considers the namespace
of the class being defined when it attempts to resolve the parent
class name, and I agree with the submitter of that report that doing
so is a bit surprising.  It can and does work, however.

On the other hand, resolving class names appearing within the body of
a class, as we're discussing here, is an altogether different
question.  I don't think there is an open issue requesting the kind of
name resolution changes you seem to want.  It makes sense to consider
namespaces from innermost to outermost, as Puppet does.  Even issue
4473 only suggests omitting the current class's namespace from those
searched for the parent class, not changing the order of the
namespaces that *are* searched.

>                            Unfortunately it looks like puppeteers expect this
> unusual name resolution order, if they ever knowingly stumble upon it
> (e.g. 4483, 4472).

Indeed, and they should.  Relative names should be resolved against
the closest namespace first, against the most distant (relevant)
namespace last.  It's more intuitive, more modular, and more
consistent with programming languages that support name shadowing.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane