Re: [Puppet-dev] metadata.json ">= 1.x" version requirements
On 26/05/17 22:50, Thomas Hallgren wrote: > In Puppet 5.0.0, where SemanticPuppet 1.0.0 is used, ">= 1.x" is a > legal version requirement. It is interpreted as '>=1.0.0'. Mixing > operator and .x branches can be somewhat confusing though, and therefore > not something that I'd recommend. Thanks for the reply. I'll revisit the test in the linter then, but may add a warning back - both for the incompatibility with Puppet 4 and for the confusing syntax. -- Dominic Cleal domi...@cleal.org -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/8644b7ac-c18c-98d2-41b2-e88230edc5ee%40cleal.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] metadata.json ">= 1.x" version requirements
Hello, In metadata-json-lint, we have an issue about whether to mark ">= 1.x" (a literal "x") version requirements as permitted or not. https://docs.puppet.com/puppet/latest/modules_metadata.html#version-specifiers states that "1.x" version requirements can't be mixed with greater/less than operators, but recently under PUP-6373, semantic_puppet started parsing them. I've opened https://github.com/puppetlabs/semantic_puppet/pull/24 to disallow them again, but is this correct? Does anybody know if a) they should start to be allowed , b) if semantic_puppet should disallow them, or c) if semantic_puppet may allow them but metadata-json-lint should disallow them? Cheers, -- Dominic Cleal domi...@cleal.org -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/aea60427-c976-b857-fd91-d3383a2d3efa%40cleal.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Nightly packages (nightlies vs. puppet5-nightly)
On 12/05/17 19:14, Melissa Stone wrote:
> On Fri, May 12, 2017 at 10:40 AM Michael Smith <mailto:michael.sm...@puppet.com>> wrote:
>
> On Friday, May 12, 2017 at 1:46:40 AM UTC-7, Dominic Cleal wrote:
>
> Hello,
>
> The second half of
>
> https://puppet.com/blog/full-visibility-and-control-of-your-infrastructure-new-puppet-releases
>
> talks about prep for Puppet 5 and new nightly packages on
> {apt,yum}.puppet.com <http://puppet.com>. I have a few questions
> about these:
>
> 1. Are these builds of the master branch(es)?
>
> Yes.
>
> 2. Do these obsolete or complement nightlies.puppetlabs.com
> <http://nightlies.puppetlabs.com>? Should I be
> testing both, or only follow puppet5-nightly now?
>
> nightlies has generally been builds from both our master and stable
> branches. I'll try to get someone more engaged with this to respond,
> because this may be changing. Following "latest" currently seems a
> little frustrating.
>
> Puppet5-nightly does obsolete nightlies.puppetlabs.com
> <http://nightlies.puppetlabs.com>, but we have no current plan in place
> to remove the infrastructure that ships to nightlies.puppetlabs.com
> <http://nightlies.puppetlabs.com>. You should still be seeing updates
> there, but I would suggest you only puppet5-nightly for development
> builds. We will eventually stop updating nightlies.puppetlabs.com
> <http://nightlies.puppetlabs.com>, but we will put out more
> communication before that happens. Puppet5-nightly is a better source
> for testing moving forward.
Thanks Melissa and Michael, I'll switch to testing puppet5-nightly now then.
--
Dominic Cleal
domi...@cleal.org
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/3a839593-7848-66b0-f3ab-535e452c3725%40cleal.org.
For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Nightly packages (nightlies vs. puppet5-nightly)
Hello,
The second half of
https://puppet.com/blog/full-visibility-and-control-of-your-infrastructure-new-puppet-releases
talks about prep for Puppet 5 and new nightly packages on
{apt,yum}.puppet.com. I have a few questions about these:
1. Are these builds of the master branch(es)?
2. Do these obsolete or complement nightlies.puppetlabs.com? Should I be
testing both, or only follow puppet5-nightly now?
3. puppet-agent on nightlies.pl.com was last updated on 3rd May and is
version puppet-agent-1.10.0.372.ge749206, while puppet5-nightly has
puppet-agent-4.99.0. Is nightlies delayed at the moment, or will it no
longer be updated?
Cheers,
--
Dominic Cleal
domi...@cleal.org
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/2449d159-9efc-f912-a368-fa0f3353f4af%40cleal.org.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet 4.10.x version comparisons
On 14/03/17 10:05, Dominic Cleal wrote: > It looks like there will be a new Puppet 4.10.x release series soon, > which I think is going to cause a few issues in tests for modules and in > supporting projects, due to reaching minor version 10. > [..] > I've opened a PR against rspec-puppet > (https://github.com/rodjek/rspec-puppet/pull/479) to fix some internal > checks and its own specs, and puppetlabs_spec_helper looks to be fine. Merged, just awaiting release. > stdlib is an example of a module that has a lot of tests with affected > version comparisons: > https://github.com/puppetlabs/puppetlabs-stdlib/blob/db8c1fbb2394d93fe3156b17c840455f1b3e2c76/spec/functions/deprecation_spec.rb#L3 https://github.com/puppetlabs/puppetlabs-stdlib/pull/737 opened to fix these tests, and David's opened https://tickets.puppetlabs.com/browse/MODULES-4528 for tracking any issues in other supported modules. Vox Pupuli modules look entirely unaffected to me. > I'll continue trying to open PRs where I can find issues, but would > appreciate help to check modules to ensure it works on release. puppet-syntax 2.4.0's been released with a fix, so I think the only supporting gems affected are it and rspec-puppet. -- Dominic Cleal domi...@cleal.org -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/0f62956c-ec02-a12e-ee5f-6e79fb2f07db%40cleal.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Puppet 4.10.x version comparisons
Hello, It looks like there will be a new Puppet 4.10.x release series soon, which I think is going to cause a few issues in tests for modules and in supporting projects, due to reaching minor version 10. In quite a few projects there are constructs such as: if Puppet.version.to_f >= 4.4 which will return false when `Puppet.version` is "4.10.0" (since "4.10.0".to_f is 4.1, not four-point-ten). These are mostly in tests, where specs might be constrained to particular versions or expect different slightly results depending on the version of Puppet. It's also possible that functions, types, or providers occasionally have version constraints. Manifests are likely safe as they should use the versioncmp() function, so this probably only really affects module tests. A safer way of comparing versions from Ruby is to use versioncmp too: if Puppet::Util::Package.versioncmp(Puppet.version, '4.4.0') >= 0 Comparisons against 4.0, 3.x etc, or using `.to_i` are going to be unaffected. It will only affect comparisons against later 4.x version numbers. I've opened a PR against rspec-puppet (https://github.com/rodjek/rspec-puppet/pull/479) to fix some internal checks and its own specs, and puppetlabs_spec_helper looks to be fine. stdlib is an example of a module that has a lot of tests with affected version comparisons: https://github.com/puppetlabs/puppetlabs-stdlib/blob/db8c1fbb2394d93fe3156b17c840455f1b3e2c76/spec/functions/deprecation_spec.rb#L3 I'll continue trying to open PRs where I can find issues, but would appreciate help to check modules to ensure it works on release. Cheers, -- Dominic Cleal domi...@cleal.org -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/103fd365-d51f-a834-b1e5-e0d3fc93933b%40cleal.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Display the contents of a yaml file
On 04/09/15 01:25, Eric Sorenson wrote: > Hi Sergiu - Which yaml file? Do you mean the output of the node > classifier? Or the file corresponding to $vardir/yaml/node/$hostname.yaml ? > > > If it's the first, it will depend on the Foreman ENC, but I believe it'd > be a call to http:///api/host/ If you're using Foreman's web UI then view the host, then click the YAML button on the left. The ENC script (node.rb) typically fetches https://foreman.example.com/node/node.example.com?format=yml. This is outside of the regular API. There's not an way to retrieve the rendered YAML in the regular authenticated API, only the above one intended specifically for the ENC script. The URL Eric suggested will give you lots of useful info about the host, but in JSON rather than Puppet's YAML ENC format. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/55E948B3.2070506%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: SELinux and Puppet Subcommands
On 26/03/15 19:25, Melissa Stone wrote: > Hi all, > > I just wanted to point out that Adrien brought up some interesting > comments in the ticket for this discussion. So that response gets more > exposure, I wanted to post it here: > > From Adrien Thebo: > > I've reviewed PR 3627 and the puppet-dev mailing list thread, and I > think that this issue could use more discussion before we start merging > things. > > First off, it doesn't seem like a lot of other projects have to deal > with this concern. Is this because the executable itself has a context > set and the process itself doesn't need to know about the context? Yes, that's the most common way. Having separate binaries helps a lot, as they can be labelled differently. > Secondly, how will this impact the JVM? Since (AFAIK) the JVM runs as a > single process with multiple services running in that process, is it > even possible to switch the SELinux context without breaking everything > else inside of the JVM? Indeed, I think a lot of these ideas are obsolete with a move towards Puppet Server and the JVM as the process startup obviously changes significantly. It probably isn't worth trying to confine the older Ruby "puppet" binary now. The SELinux context will be process-wide, so affects all services within the JVM, so any policy that would be created would have to cover all services that might run inside it. > And now for more implementation oriented questions: > > > SELinux domains > > What domains do we need for Puppet + SELinux? What resources do they > need access to? Confining anything that listens on the network should probably be the priority, i.e. the master, as that's the main attack surface. A policy would have to give access to any local state files it uses, config files, modules, through to any network connections it makes too. > > Configuration via environment variables > > The current pull request uses the following environment variables: > > * NO_PUPPET_SELINUX_DTRANS > * PUPPET_SELINUX_MASTER_DOMAIN > * PUPPET_SELINUX_CA_DOMAIN > > Right now Puppet doesn't use ENV for configuration; it has a few trivial > things like looking at 'PATH' and 'HOME' but doesn't read values out in > order to configure itself. Using the environment to configure the > SELinux context means that we have a new configuration mechanism that > will not be documented along with other settings. Using environment > variables for configuration means that if different values are needed, > they won't "stick" - there's no way to always apply these settings > without modifying init scripts or /etc/profile or the like. > > This leads into... > > > Environment variables vs configuration via a file > > Dominic Cleal indicated that we should change the SELinux context before > we read any configuration files, which makes us need an alternate method > of configuring SELinux, which the reason of running unconfined for as > little time as possible. Why? Doing so makes it more challenging to > handle configuration. Is it really that risky to run unconfined until we > can read a config file to get SELinux settings? If we do run unconfined > long enough to read a config file, what are the potential ramifications > of running unconfined for this period? I suppose what we would want to avoid is a period in which something external, such as a user on the network (probably not an issue) or some untrusted code is loaded or executed that could access resources that the server wouldn't have access to when confined. As a hand waving example, if we loaded environments and executed custom types, or configuration somehow referenced another file (/etc/shadow for argument's sake) which was read before confining the server, then this wouldn't be ideal. Confining the process earlier would help. > Switching contexts for packaged installs vs gem installs > > It was proposed that we don't switch SELinux contexts if Puppet was > installed via a gem or run from source. This seems really challenging to > implement. > > > Switching contexts for different users > > If I'm developing on Puppet and standing up a test master as my own > user, I really don't want SELinux turning itself on. How can we prevent > this? > > > Opt-out vs opt-in > > The current approach takes an opt-out approach to SELinux; if it's > opt-in we avoid the issue of switching contexts for packaged installs vs > gem installs. Is this a viable option? Indeed, opt-in makes sense to fix those problems. Or, if the entire process can be confined by using filesystem labels or a systemd unit file (SELinuxContext
Re: [Puppet-dev] Thoughts on Module Namespace Conflicts
On 11/02/15 18:13, Trevor Vaughan wrote: > Heh, that's probably because it's the third hit in the list when you > search for Apache on the Forge. > > Is there a way for people to mark Forge modules as unmaintained? Not as far as I know. I ought to upload a new release with a big warning in the README. All I've done for the meantime is add a "deprecated" tag, which isn't a big help. There's a similar issue I have with augeasproviders. Again I've yet to update the README in domcleal/augeasproviders to indicate that herculesteam/augeasproviders is the maintained version, but it would be great to be able to mark this as such in the Forge, or even redirect to another module. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54DC72AD.9000103%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Thoughts on Module Namespace Conflicts
On 10/02/15 00:23, Trevor Vaughan wrote: > I was talking with a few folks today about potential resolutions to > module namespace issues. > > == Fundamental Issue == > > puppetlabs_apache -- Installs To --> apache > example42_apache -- Installs To --> apache > theforeman_apache -- Installs To --> apache > > You get my point... I do, but just for the avoidance of doubt, and because I still get asked about it regularly, theforeman/apache is dead and has been replaced by puppetlabs/apache for a couple of releases now. Long live pl-apache :-) -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54DB2DE9.20001%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Anyone scripting around certificate authority? (puppet-dev version)
On 22/12/14 20:01, Eric Sorenson wrote: > [ sorry for the double-post, I sent this to puppet-users as well, but am > posting separately here to keep the threading separate.. Damn reply-to > munging ] > > Hiya, one of the cool things in the new Puppet Server is a > re-implementation of Puppet's certificate authority code. The > implementation up to last week's 1.0.0 release is pretty strictly > backwards-compatible with the Ruby implementation, using the same > filesystem layout, same HTTP endpoints, etc., but early next year we > need to start making some changes and I wanted to solicit some feedback > to see what y'all are using. So, some questions: > > - Are you using scripts which run and parse output from `puppet cert`, > `puppet certificate`, `puppet ca`, `puppet certificate_request` and/or > `puppet certificate_revocation_list`? If so, what do the scripts do with > the commands, and what output do they expect? (As an aside one of the > problems we're aiming to fix is the multiplicity of confusingly > overlapping functionality available in these subcommands) Foreman's smart proxy (a management agent) uses `puppet cert`. You can find it here: https://github.com/theforeman/smart-proxy/blob/develop/modules/puppetca/puppetca_main.rb It uses "puppet cert --list --all", "puppet cert sign" and "puppet cert clean". sign/clean are just basic execution, but listing appears to parse the output very precisely, so I expect any change in output format would break it. "puppet cert --generate" is also used to generate a CA and certificate when setting up a Puppet master in this module: https://github.com/theforeman/puppet-puppet/blob/2.3.1/manifests/server/config.pp#L62-L66 (usually run from puppet apply). > - Are you using the HTTP API around certificates in your own > tooling/automation? These are endpoints like `/certificate/ca`, > `/certificate/`, > `//certificate_revocation_list/ca` , > `//certificate_request/`, > `//certificate_status` Same question -- what do you use > the endpoints to accomplish, and are there particularly important pieces > of data in the output for your use-cases? I'd prefer to reimplement it against the API, incidentally. A change in the CLI might be a good reason to do it. > - Are you using any programs which load the Puppet Ruby code as a > library in order to make use of the certificate-related classes/methods > directly? Is that because there was something you couldn't do through > the command-line or REST APIs? I would be pretty surprised if anyone was > doing this but you're going to have to make the deepest changes so it's > important for me to understand what you're relying on. Not for certificates. > - Are you making use of stuff that lives in the CA filesystem in your > own tooling, that does NOT go through any of the Puppet APIs? If so, > STOP DOING THAT! Just kidding, sorta. But it would be very interesting > to know whether you're using things like the `serial` or `inventory.txt` > files in your scripts or workflows. By default, Foreman re-uses Puppet certificates and keys, so the locations are important, however they're not modified. Cheers, -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54B64E69.9090801%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Exiting; failed to retrieve certificate and waitforcert is disabled
On 10/11/14 09:21, Alick wrote: > > Environment : > > Puppet Master/Agent Version: 2.7.14 > Master/Agent run with "root" account > > Device which Agent running on do not has enough rootfs space to install > puppet 3.x version, so i use 2.7.14 in both master & agent. > > IP connection between Agent & Master is ok. Domain ping between > Master & Agent is ok. > > > --- Full Agent Logs > - > > ~ # puppet agent --no-daemonize --verbose --onetime --debug --trace > warning: iconv couldn't be loaded, which is required for UTF-8/UTF-16 > conversions > info: Redefining file in Puppet::Type > /lib/ruby/gems/2.1.0/gems/puppet-2.7.14/lib/puppet/util/classgen.rb:146:in > `remove_const' I would suggest running Puppet 2.7.14 on Ruby 2.1.0 (if I'm reading your stack trace correctly) is going to cause you no end of pain, unless you try to backport a lot of fixes. http://docs.puppetlabs.com/guides/platforms.html#ruby-versions 2.7 didn't even fully run on 1.9. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/546087F5.4050204%40redhat.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] #puppethack and Contributor Summit
In case you missed it, there's an IRC-based hack day planned in December, and a contributor summit again in Ghent next year: http://puppetlabs.com/blog/puppethack-online-community-hack-day -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/543E3BB4.3070706%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Running Beaker tests in a Public CI
On 01/10/14 15:27, Trevor Vaughan wrote: > How does running tests with SELinux contexts work in a Docker instance? > (I'm not guessing very well, but it would be nice to have confirmation). I think the way it works recently (since Dan Walsh's work around Docker 0.10/11) is that /sys/fs/selinux is read-only inside the container, and libselinux understands this as "SELinux is disabled". As far as selinuxenabled etc are concerned, there's no SELinux support, so the same as running on a normal host or VM without SELinux enabled. (This is separate to whether SELinux is functional on the host running the container.) https://bugzilla.redhat.com/show_bug.cgi?id=1096123 has some interesting background, as EL6's libselinux didn't understand what the read-only /sys/fs/selinux mount meant. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/542D043D.7010802%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Announce: Puppet Server 0.2.0
On 23/09/14 17:11, Nate Wolfe wrote: > We are thrilled to announce the preview release of Puppet Server, our > newest open source project. > Puppet Server is a next-generation alternative to our current Puppet > master, which builds on the > successful Clojure technology stack underlying projects like PuppetDB. > > Packages are available in the Puppet Labs package repositories, so you > can try it out today as a > drop-in replacement for the existing Puppet master. Very neat, it works well as a drop-in replacement. The only hitch I've had was with the Foreman report processor, which makes an HTTPS connection to Apache with mod_ssl. On new OSes with modern mod_ssl versions (e.g. EL7 or Ubuntu 14.04), the report processor fails to make an HTTPS connection from the JVM with the error: 2014-09-26 08:56:09,984 ERROR [puppet-server] Report processor failed: Could not send report to Foreman at https://foreman.example.com/api/reports: Could not generate DH keypair ["sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1287)", ...] This is a well-known problem between JVM clients and recent mod_ssl versions, as the DH prime length supported by the JVM is limited. Adding the DH parameter limits to the server's certificate worked around the problem. http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh Java 8 worked slightly better in that it accepts 2048 bit parameters, but the default combination is still a problem. I guess it might affect others using HTTPS from the master. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54253A9A.3040306%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Announce: nightly repos available
On 04/09/14 01:50, Matthaus Owens wrote: > Dominic, > Facter master just passed acceptance with trusty, so it is now > available in the nightly repos. Great, thanks. Looks like it got further, but failed on an obscure issue between the Foreman API and one of our types/providers. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54081FE9.6040401%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Announce: nightly repos available
On 03/09/14 01:00, Kylo Ginsberg wrote: > On Fri, Aug 29, 2014 at 1:55 AM, Dominic Cleal <mailto:dclea...@redhat.com>> wrote: > > On 26/08/14 18:23, Eric Sorenson wrote: > > The repos are live now and you can try them out by following these > directions: > > > > https://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#using-the-nightly-repos > > It appears that Ubuntu 14.04 (trusty) packages are missing from the > Facter nightlies, though Puppet's present. Could they be built too? > > Otherwise I'm happy to say that the Foreman test suite is green on EL6, > F19, Debian 7 (Wheezy) and Ubuntu 12.04, with Puppet and Facter > nightlies. It'll run twice a week from now on, testing a bunch of > modules, master/agent setups and Foreman integration. > > > That is great! Is this on http://ci.theforeman.org/? If so, which jobs? > I'm curious to see details of what is tested. That's right. The exact job is: http://ci.theforeman.org/job/systest_foreman_puppet_nightly/ (current F19 failure is in our nightlies, trusty is due to the missing Facter nightly repo) It runs a BATS-based test suite using Vagrant on Rackspace Cloud: https://github.com/theforeman/foreman-bats This simply configures repos, then runs foreman-installer, which is a Kafo-based tool around Puppet modules for setting up Apache, PostgreSQL, Passenger-based Puppet master and Foreman instance. https://github.com/theforeman/foreman-installer https://github.com/theforeman/kafo It then downloads some modules from the Forge, imports them into Foreman and checks they apply via the agent. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5406D85A.3020504%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Announce: nightly repos available
On 29/08/14 09:55, Dominic Cleal wrote: > On 26/08/14 18:23, Eric Sorenson wrote: >> The repos are live now and you can try them out by following these >> directions: >> https://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#using-the-nightly-repos > > It appears that Ubuntu 14.04 (trusty) packages are missing from the > Facter nightlies, though Puppet's present. Could they be built too? Another useful addition would be the Puppet gem, as Facter's is already there. I've got another battery of tests that could be run against it. Cheers, -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5400A7A4.5080002%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Announce: nightly repos available
On 26/08/14 18:23, Eric Sorenson wrote: > The repos are live now and you can try them out by following these directions: > https://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#using-the-nightly-repos It appears that Ubuntu 14.04 (trusty) packages are missing from the Facter nightlies, though Puppet's present. Could they be built too? Otherwise I'm happy to say that the Foreman test suite is green on EL6, F19, Debian 7 (Wheezy) and Ubuntu 12.04, with Puppet and Facter nightlies. It'll run twice a week from now on, testing a bunch of modules, master/agent setups and Foreman integration. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54004012.5040201%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] SELinux and Puppet Subcommands
On 28/08/14 20:39, Lukáš Zapletal wrote: > An addendum: if a user installs Puppet from a gem or source (for > instance) onto an OS release that doesn't have a working policy for > that > version of Puppet, they will probably want to disable the context > switch. Config of this sort, or a command line argument might work? > > > This is contradictory to your context switch before reading config > suggestion. Indeed, to an extent. I was thinking of something more hard coded for SELinux contexts, while ensuring a context switch before "puppet ... --config [path]" allowed reading of arbitrary files > I think when using a gem install, no SELinux transition should be ever > commited. It is not expected to have SELinux protection for gems. So by > default this would be turned off and distributions would turn this on. > > As you suggest, if this (and the domains to transition into) are in a > separate "support" file, this would make distribution patching piece of > cake. This would require three "echo" commands in a SPEC file (turn on, > domain for puppet master, domain for puppet ca). Yeah, that makes sense I think. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54002E84.1020203%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Announce: nightly repos available
On 28/08/14 17:17, Henrik Lindberg wrote: > On 2014-28-08 9:13, Dominic Cleal wrote: >> On 26/08/14 18:23, Eric Sorenson wrote: >>> After the Puppet 3.5.0 release problems, we had a retrospective and tried >>> to figure out some process improvements which would have surfaced the >>> problems earlier. Despite a lengthy 4-week release candidate cycle, that >>> release still had a fatal flaw that nobody had caught until it went into >>> final release. As we talked it over, our thoughts turned to continuous >>> delivery. Puppet (along with most of the other open-source projects) >>> already produces packaged artifacts as moves through our Jenkins pipeline, >>> so it seemed like a natural step to make those packages publicly available. >>> >>> In lieu of release candidates, we are moving toward a more automated system >>> which will have the latest green builds (passed spec and Beaker acceptance >>> tests) cut off the 'master' branch for most of our projects. >> >> Would it be possible to build packages for other branches (like >> puppet-4, or facter-2 when it was in development) in the future? I'm >> especially interested in tracking incompatible Puppet 4 changes. >> > > We really hope that the puppet4 and facter2 branches were a special > circumstance. It is not our intention to have long running feature > branches. As soon as 3.7.0 is released, the puppet4 branch will be > merged to master, and the puppet4 branch will be retired. > > Since 3.7.0 is about to be released very soon there will not be any > puppet4 builds in nightly (until it is on master). Okay, that makes sense. Thanks Henrik. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53FF56B3.2080709%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] SELinux and Puppet Subcommands
On 28/08/14 10:01, Dominic Cleal wrote: > 2. names of SELinux domains are most likely governed by the distribution > rather than the Puppet project, as at least in Fedora and EL, an SELinux > policy for Puppet is shipped as part of the base targeted policy and not > as part of Puppet. > > This means that Puppet should probably ship with a sane suggestion of > SELinux domains to transition to (e.g. the master application runs in > the puppetmaster_t domain), but packagers may want to be able to > override it relatively easily - perhaps this is a patch, but perhaps > something more like a config file containing a lookup table would be > easier to maintain. An addendum: if a user installs Puppet from a gem or source (for instance) onto an OS release that doesn't have a working policy for that version of Puppet, they will probably want to disable the context switch. Config of this sort, or a command line argument might work? -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53FEF2A4.1080100%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] SELinux and Puppet Subcommands
On 27/08/14 20:00, Joshua Partlow wrote: > Hi everyone, > > There is a PR for Puppet to address difficulties setting security > contexts in SELinux for specific puppet subcommands > (https://github.com/puppetlabs/puppet/pull/2997). The contributer (Lukáš > Zapletal) originally was looking to add additional wrapper scripts > around subcommands so that a puppet_exec_t could be set for these files. > There is general concern about the confusion caused by reintroducing > separate commands, and Dominic Cleal suggested making use of Ruby's > SELinux bindings (specifically Puppet::Util::SELinux.setcon in Puppet) > to instead handle the context switch internally. If taking this approach, I think there are two important points. 1. the context switch should be made as soon as possible, to minimise the window when running unconfined. In particular I think we should avoid reading in config files at this stage, if that's possible. It looks like the Puppet::Util::CommandLine code isn't going to load configs yet, so changing context within here (e.g. ApplicationSubcommand) or perhaps inside Puppet::Application is possible. 2. names of SELinux domains are most likely governed by the distribution rather than the Puppet project, as at least in Fedora and EL, an SELinux policy for Puppet is shipped as part of the base targeted policy and not as part of Puppet. This means that Puppet should probably ship with a sane suggestion of SELinux domains to transition to (e.g. the master application runs in the puppetmaster_t domain), but packagers may want to be able to override it relatively easily - perhaps this is a patch, but perhaps something more like a config file containing a lookup table would be easier to maintain. Cheers, -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53FEEFD7.8000806%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Announce: nightly repos available
On 26/08/14 18:23, Eric Sorenson wrote: > After the Puppet 3.5.0 release problems, we had a retrospective and tried to > figure out some process improvements which would have surfaced the problems > earlier. Despite a lengthy 4-week release candidate cycle, that release still > had a fatal flaw that nobody had caught until it went into final release. As > we talked it over, our thoughts turned to continuous delivery. Puppet (along > with most of the other open-source projects) already produces packaged > artifacts as moves through our Jenkins pipeline, so it seemed like a natural > step to make those packages publicly available. > > In lieu of release candidates, we are moving toward a more automated system > which will have the latest green builds (passed spec and Beaker acceptance > tests) cut off the 'master' branch for most of our projects. Would it be possible to build packages for other branches (like puppet-4, or facter-2 when it was in development) in the future? I'm especially interested in tracking incompatible Puppet 4 changes. (http://copr-fe.cloud.fedoraproject.org/coprs/domcleal/puppet4-nightly/ are my builds of puppet-4.) > What this means is that as we near feature complete on a release, like the > coming Puppet 3.7.0 release, users like yourself can begin trying out the > packages to ensure that the new features haven't broken anything you depend > on, and that the new features work the way you expect/want them to. > > The repos are live now and you can try them out by following these directions: > https://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#using-the-nightly-repos > > Hopefully this will help get faster turnaround AND better coverage. Please > let us know if you find it useful! This is great, many thanks. I had been building RPMs on copr (dead easy with Puppet's packaging helpers) and running Foreman's installer & smoke tests with them, which helped us spot incompatible changes and regressions quickly. I'd encourage everybody to do something similar if they have a similar test suite, it's been very valuable. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53FED67E.9090608%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Rubygems in Puppet modules, revisited
On 28/04/14 16:45, R. Tyler Croy wrote:
> In my previous thread "Can I make my entire module "depend" on
> rubygems being installed?" I think I mischaracterized the problem.
>
>
> Basically, I would like to use a Ruby gem inside of a Puppet module
> which contains a custom provider. There's an inherent problem in
> this appraoch, for example:
>
> class { 'jenkins' : require => Package[mygem]; }
>
> This iwll require *two* Puppet runs to operate correctly, one to
> install the gem properly, and the second to load the gem properly
> into the Puppet runtime environment.
This is possible using "features" (that is, system features, not
provider features). You first write a feature definition that says
you expect library X to become available. You then confine your
provider to depend that feature being available, the Puppet will delay
evaluation of those resources until the feature becomes available in
the same way it does with commands. This has been available since
2.7.20 (ticket #14822).
Here's an example of a feature:
https://github.com/theforeman/puppet-foreman/blob/master/lib/puppet/feature/foreman_api.rb.
The "libs" argument has to be the name of the library passed to require.
The confine looks like this:
https://github.com/theforeman/puppet-foreman/blob/master/lib/puppet/provider/foreman_smartproxy/rest.rb#L3
However there's a gotcha if you're requiring gems, as we have to flush
the load paths or they get cached with the currently loaded set of
gems. This has only just been fixed for Puppet 3.6.0:
https://tickets.puppetlabs.com/browse/PUP-1879
I can't really think of a workaround for this issue either, unless you
can figure out how to run some arbitrary code after each resource is
evaluated to clear cached paths.
--
Dominic Cleal
Red Hat Engineering
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/535E7B1B.4030808%40redhat.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev]
On 06/04/14 15:49, Andy Parker wrote: > 2 Put directory environments behind a feature flag (disabled by default) > - PRO: completely removes the possibility of unwanted collisions > - CON: users will have to take extra action to use the new system. > PE will > have to ensure that they are enabled and the migration is done. I prefer this option, it's clean and as Spencer said, other new features work in the same way. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53426165.7020501%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Directory Environments
On 25/02/14 15:59, Dominic Cleal wrote: > On 21/02/14 08:41, Joshua Partlow wrote: >> Hi folks, >> >> (TL;DR: in 3.5.0+ environments will change to be named directories with >> a specific structure and configurable defaults, all to be found in a >> configured 'environmentpath') > > Thanks for the detailed explanation Josh, this was really useful. It > sounds like a good direction. My only concern is the complete removal > of static and dynamic environments in Puppet 4.0, which could be > problematic for users who have built workflows around the ability to > define complex environment modulepaths. Ignore that comment please, I missed the references to PUP-1596. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/530CE571.8020809%40redhat.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Directory Environments
On 21/02/14 08:41, Joshua Partlow wrote: > Hi folks, > > (TL;DR: in 3.5.0+ environments will change to be named directories with > a specific structure and configurable defaults, all to be found in a > configured 'environmentpath') Thanks for the detailed explanation Josh, this was really useful. It sounds like a good direction. My only concern is the complete removal of static and dynamic environments in Puppet 4.0, which could be problematic for users who have built workflows around the ability to define complex environment modulepaths. I've been doing a little regression testing and came across the following bug with "puppet apply --modulepath": https://tickets.puppetlabs.com/browse/PUP-1765 Do you have any thoughts on the correct way to resolve this? The current implementation appears unintuitive. My inclination is that the combined loader should treat settings that have been overridden on the command line with higher priority than the environmentpath loader, but environments in puppet.conf at a lower priority. (I suspect in practice, this could be tricky to implement.) -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/530CBDE3.8080809%40redhat.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev]
On 16/12/13 19:54, Andy Parker wrote: > On Mon, Dec 16, 2013 at 11:51 AM, Dominic Cleal <mailto:dcl...@redhat.com>> wrote: > > On 16/12/13 19:38, Andy Parker wrote: > > We did another PR triage hangout. There were a few people who showed > > up…and our manners were not the greatest so they quickly dropped back > > off before we even got to find out who they were. We'll be working on > > that to make sure that the hangouts are more inviting. I also need to > > figure out a way of making them more prominent. What should we do > to get > > more people showing up? > > A bit more warning would be good, I missed it as the last notification > went out on the same day. > > > Would posting to this list with a link about 24 hours in advance be > good? Or is there some other way I should set it up? Shared calendar maybe? 24 hours would just about be enough. Another way might be a Google+ event and/or Google+ community, but this list is probably the best way to let most developers know about it. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/52AF5F33.4040804%40redhat.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev]
On 16/12/13 19:38, Andy Parker wrote: > We did another PR triage hangout. There were a few people who showed > up…and our manners were not the greatest so they quickly dropped back > off before we even got to find out who they were. We'll be working on > that to make sure that the hangouts are more inviting. I also need to > figure out a way of making them more prominent. What should we do to get > more people showing up? A bit more warning would be good, I missed it as the last notification went out on the same day. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/52AF59B8.3030702%40redhat.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Referencing other resources in parameters
On 21/08/13 21:12, Trevor Vaughan wrote: > Interesting. I was thinking that he would be using the resource as part > of a type value. I suppose if you pass it directly to the provider it > would work but it seems that any manipulation in the type itself > wouldn't work. > > Happy to be wrong though. I suspect there's some truth to what you're saying, depending on when the value's used. If I was trying to access the other resource from the type's parameter setter or similar, then I suspect this would be parse order dependent. Using the other resource from a provider in the compiled catalog, should be late enough in the process that it's fully accessible. Thanks for your feedback Dan and Trevor. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet-dev] Referencing other resources in parameters
Hi all,
A bit of an open-ended question, but has anybody designed custom types
with parameters that reference other resources? Are there any 'gotchas'
to be aware of, or functionality that this can break?
The types in this case are for SSL certificate handling and the thought
is to have a type representing a CA and resources for certificates
signed by that CA. Instead of duplicating the parameters and data for
the CA on the certificate resources, you'd reference the CA resource
itself. For example:
ca { 'my-ca':
ensure => present,
common_name => $fqdn,
country => $certs::ca_country,
state => $certs::ca_state,
city=> $certs::ca_sity,
org => $certs::ca_org,
org_unit=> $certs::ca_org_unit
}
cert { 'qpid-broker':
ensure => present,
ca => Ca['my-ca']
}
The 'cert' type could retrieve any data it needed from the Ca[my-ca]
resource.
Of course, the relationship metaparameters do reference individual or
arrays of other resources in the catalog, and a quick test of this
appears successful.
Is this supported for ordinary, non-metaparameters and could it cause
any problems? I'm thinking of layered projects such as PuppetDB, if it
would be able to import catalogs containing these references.
Thanks,
--
Dominic Cleal
Red Hat Engineering
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Stop the new-hotness cycle..
On 15/08/13 19:31, Andy Parker wrote: > Other efforts to engage people with the new ideas may help, as > well. The ARMs are pretty deeply technical documents, so perhaps > these hangouts or office hours can be a place for users to start > with a quick summary of the ARM, and then drill down into potential > concerns. > > > Looking at Eric's calendar it looks like the "ARM Office Hours" are > 1:30-3:30pm Pacific every Tuesday. Is that a good time? Should we open > them up to more general office hours? Maybe have one of the devs > available at the same time to talk about anything? It might be useful to run a dedicated hangout session, invite the ARM author to outline the proposal and discuss it that way too. If recorded, this also becomes a good development resource in the future. I also like the idea you suggested in an earlier message to have a weekly general development hangout. The only trouble with these is ensuring the result is transparent, so if decisions are made then they're recorded on redmine tickets or in PR comments. > We've also been making an effort to spend more time in #puppet-dev > recently, which seems to be resulting in a lot more information making > it out. I've noticed this and I really appreciate it - thank you. Even if some of us aren't engaged in the conversation, we're soaking it up. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] ruby-1.9.3 in yum.puppetlabs.com
On 25/07/13 16:21, Justin Lambert wrote: > For RHEL derivatives one option might be Redhat's Software Collections. > They have added Ruby 1.9.3 support to RHEL through that. I have > testing it out on my todo list, but haven't made it that far yet. I'm > not quickly finding a link to the actual RPM, but here's their PDF about > it: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/1/html-single/Software_Collections_Guide/index.html For RHEL, it's available as a beta child channel via RHN. There's also an older repo up here from when it was being developed that other EL users could try: https://fedorahosted.org/SoftwareCollections/ We're using the ruby193 SCL for Foreman actually (packages on http://yum.theforeman.org/), which has worked pretty well. The advantage is unlike replacing the distro packages (as was done with EL5 and 1.8.7), you don't break distro support or ABI/API compatibility for other packages depending on Ruby. Though a downside for some users may be additional packages on their base OS install. Unlike with Foreman's use where it's just one central host, this would be for every host running an agent. However I don't see that this has much to do with the original bug, which was more luck than design that it was fixed in 1.9.3... it's not worth investigating 1.9.3 support via packages just to provide a workaround for that issue! Charlie's last response is spot on. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Writing Rspec Tests w/Mocha
On 18/01/13 07:30, John Julien wrote: > Hi, > I'm adding the feature :libuser to Puppet::Type::Group. In the groupadd > provider, having the feature libuser and setting forcelocal => true will > cause the invoked command to be lgroupadd instead of groupadd. I want > to write a test case for both when the libuser feature is present and > when its not. > > I'm seeing a lot of test cases written like: >describe "on system that feature system_groups", :if => > described_class.system_groups? do > > This appears to restrict the test case from being run only on systems > that actually support the system_groups feature. I would like to write > a test case that, within the groupadd provider, emulates both having and > not having the libuser feature and making sure that the command > lgroupadd and groupadd are used respectively. > > I thought I could accomplish this by executing >provider.stubs(:feature?).with(:libuser).returns(true) > > But I end up getting unexpected invocation errors because > provider.features? gets executed by Puppet::Type::Group with other > parameters than :libuser. The method you want to stub is actually on Puppet.features: has_feature :libuser if Puppet.features.libuser? So you'd be using: Puppet.features.expects(:libuser?).returns(true) The trouble in this case, and the reason I think the other tests only run on systems with those features, is that *provider* features aren't re-evaluated at all. This is logged as issue #2384, but it's mostly a problem for libraries which can be installed during a run and require re-evaluation of features. When the provider is initially evaluated, the if feature statement is going to get evaluated, but not again. This means if you come to stub the *system* libuser feature in the test harness, it won't change the evaluation that's already happened for the provider's feature. I think if you're going to implement this as a provider feature, you'll have to test it in a similar way to system_groups. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Outcomes from weekly planning
On 19/12/12 19:04, Andy Parker wrote: > On Wed, Dec 19, 2012 at 3:16 AM, Dominic Cleal <mailto:dcl...@redhat.com>> wrote: > > On 19/12/12 01:36, Andy Parker wrote: > > In addition we've been pulling in pull requests that have been related > > to the work on code loading and settings as part of the final work for > > #7316. > > * PR puppet/1332 - puppet 3, rspec, and custom resources are broken > > * PR puppetlabs_spec_helper/29 - needs to initialize TestHelper > > * PR puppet/1316 - re-initialize settings metadata after run_mode > > determined > > Great, I'm looking forward to this working! I recently hit a very > similar issue on 2.7.20 where types wouldn't load when using rspec, but > it was caused by something different. I'd appreciate it if this PR > could be looked at soon, so it's fixed in case there's another 2.7.x > release: > > https://projects.puppetlabs.com/issues/18187 > https://github.com/puppetlabs/puppet/pull/1339 > > > I just took a quick look and added a comment. I'll leave it to Jeff to > handle it though. Thanks. > On the status of 2.7.x, I was hoping that 2.7.20 would be the last > release barring any big bugs or security problems. Do you think this is > a big enough issue to warrant a 2.7.21? I don't think so, it only affects testing of modules with types. My hope was it could go into the tree, in preparation for a security release. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Outcomes from weekly planning
On 19/12/12 01:36, Andy Parker wrote: > In addition we've been pulling in pull requests that have been related > to the work on code loading and settings as part of the final work for > #7316. > * PR puppet/1332 - puppet 3, rspec, and custom resources are broken > * PR puppetlabs_spec_helper/29 - needs to initialize TestHelper > * PR puppet/1316 - re-initialize settings metadata after run_mode > determined Great, I'm looking forward to this working! I recently hit a very similar issue on 2.7.20 where types wouldn't load when using rspec, but it was caused by something different. I'd appreciate it if this PR could be looked at soon, so it's fixed in case there's another 2.7.x release: https://projects.puppetlabs.com/issues/18187 https://github.com/puppetlabs/puppet/pull/1339 -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] file concat library
Hi Richard, On 18/12/12 04:00, Richard Pijnenburg wrote: > Hi all, > > I got a native file concat library which i believe could be very useful. > Current implementations of file concat's work with temporary files and > finds and can cause issues. > > the library can be found at > https://github.com/electrical/puppet-lib-file_concat > > Im pretty sure it will need some work to make it clean and lean but its > a good beginning i think. > > Wonder what you all think of this. Not meaning to rain on your parade, but there's another native concat module which works pretty well: https://github.com/onyxpoint/pupmod-concat As you say, there are good benefits to this over an exec based implementation, such as --noop support. Unfortunately there were some issues stopping it being merged in core: http://projects.puppetlabs.com/issues/7688 -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Any advice on "Puppet::Util::Log requires a message" failure
On 11/12/12 17:21, Roman Shaposhnik wrote: > Hi! > > all of a sudden the puppet code that deploys Hadoop > clusters in Bigtop started to trigger: > err: /Stage[main]/Hadoop_head_node/Solr::Server[solrcloud > server]/Solr::Solrcloud_config[collection1]/Exec[ZK collection1 config > upload]: Could not evaluate: Puppet::Util::Log requires a message > > The behavior is not 100% reproducible and it doesn't > happen with the same resource in different runs, but > within the entire run it is almost guaranteed to happen. > So far -- I've seen it triggered for Exec and Package > resources. > > This happens with quite a few different Puppet versions > I tried (2.6.X, 2.7.X) on various Linux distros (RHEL, SLES) > so I suspect this is a combination of a Puppet issue (perhaps > this one: http://projects.puppetlabs.com/issues/17887 ) > and something in my code that is triggering it. > > Taking a hint from the proposed fix to the bug report > I quoted above, I was able to generate the stacktrace > at the point where it happens (attached). During a run is odd, since I normally see it in a test harness where rspec/mocha performs some sort of quick exit, bypassing the exception routines. Have you tried applying the patch I wrote for the issue? https://github.com/puppetlabs/puppet/pull/1307/files https://github.com/domcleal/puppet/commit/6662ef4.patch > Here's the snippet of code I inserted in puppet/util/log.rb > > begin > raise ArgumentError, "Puppet::Util::Log requires a message" unless msg > @message = msg.to_s > rescue => e > @message = "EMPTY MESSAGE: " + e.backtrace.to_s > end > > and here's the resulting stack trace (as you can see it is now failing > in a different resources but failing nonetheless): > > notice: > /Stage[main]/Hadoop_head_node/Hadoop::Create_hdfs_dirs[/var/log]/Exec[HDFS > init /var/log]/returns: EMPTY MESSAGE: > /usr/lib/ruby/site_ruby/1.8/puppet/util/log.rb:222: > in `message='/usr/lib/ruby/site_ruby/1.8/puppet/util/log.rb:203 > in `initialize'/usr/lib/ruby/site_ruby/1.8/puppet/util/log.rb:81 That's the trouble with the error, it's triggered from within the logging code and so it doesn't show you the context of what's happening inside the run. > in `new'/usr/lib/ruby/site_ruby/1.8/puppet/util/log.rb:81 > in `create'/usr/lib/ruby/site_ruby/1.8/puppet/util/logging.rb:7 > in `send_log'/usr/lib/ruby/site_ruby/1.8/puppet/transaction/event.rb:38 > in > `send_log'/usr/lib/ruby/site_ruby/1.8/puppet/transaction/resource_harness.rb:126 This looks like the same area (while applying a property change), try the patch. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] master first?
On 01/08/12 01:08, Ashley Penney wrote: > On Tue, Jul 31, 2012 at 7:42 PM, Andy Parker wrote: > >> Would that make it easier for you? The change on our end would be that >> github pull requests would just be a staging area for code and we often >> wouldn't use it for merging (which is not a big loss). > > I think that might be a positive change in that I love using pull requests for > work in progress. It's an ideal way to send something to Puppetlabs > developers > as a kind of request for feedback. If that's what you mean by staging area > for > code then I think that's probably ideal. People work in master and > then Puppetlabs > merge things back to stable branches. I wonder what this merging back process would look like. Would you have a way to suggest a particular commit for backporting, via another ticket or some other mechanism? Would Puppet Labs be committing to backport anything that looks like a bug? As somebody who has submitted code to the "wrong" branch a number of times, I think this would be a useful change. I've submitted patches to master (that became Telly) over a year ago and it's a shame that they're still unreleased because I hadn't chosen the right branch. I was probably taking the "bug fixes only" policy of 2.7.x more literally than was actually the case. With a consistent master-first and backport policy we could follow, it might make development easier and more transparent to people wondering why changes are in one version and not another. Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Accessing Puppet::Property::List elements
On 18/07/12 20:58, Stefan Schulte wrote: > On Mon, Jul 16, 2012 at 11:19:52AM +0100, Dominic Cleal wrote: >> Hello, >> >> I'm currently implementing a new provider for the mounttab type (the one >> distributed in the puppetlabs/mount_providers module) in the >> augeasproviders[1] project. >> >> From the provider I need to access the list of options given in the >> mounttab resource, defined in the type as: >> >> newproperty(:options, :parent => Puppet::Property::List) do >> def delimiter >> "," >> end >> end >> >> The trouble with this is the type appears to be defining how the >> property is stored by specifying the delimiter, something that's >> normally the preserve of the provider. Since I'm passing the options >> into Augeas, I actually would like the original list of options to avoid >> parsing them back out of the joined string available from >> resource[:options]. >> >> Does anybody know how to get at this original list? >> >> [1] https://github.com/domcleal/augeasproviders / >> http://forge.puppetlabs.com/domcleal/augeasproviders >> > > I guess this should work: > > resource.original_parameters[:options] > > but this would not merge the should values with the current values > if membership is set to minimum. Thanks Stefan, that worked perfectly. -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] Accessing Puppet::Property::List elements
Hello, I'm currently implementing a new provider for the mounttab type (the one distributed in the puppetlabs/mount_providers module) in the augeasproviders[1] project. >From the provider I need to access the list of options given in the mounttab resource, defined in the type as: newproperty(:options, :parent => Puppet::Property::List) do def delimiter "," end end The trouble with this is the type appears to be defining how the property is stored by specifying the delimiter, something that's normally the preserve of the provider. Since I'm passing the options into Augeas, I actually would like the original list of options to avoid parsing them back out of the joined string available from resource[:options]. Does anybody know how to get at this original list? [1] https://github.com/domcleal/augeasproviders / http://forge.puppetlabs.com/domcleal/augeasproviders -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] why I don't feel that ENCs are very functional right now (performance)
On 18/06/12 18:22, Jo Rhett wrote: > On Jun 17, 2012, at 4:22 AM, Dominic Cleal wrote: >> Yes, prior to 3.0 it is a lot slower. The reason's simple, it loads and >> parses every file unless you explicitly tell it (via lens/incl params) >> which file you intend to edit. >> >> 3.0 has an optimisation (#7285) so if you use the context param then it >> uses this to load only the subset of files matching the context given. >> This should significantly speed up resources where context is given >> (usually the case) by eliminating a lot of I/O. > > Is there any reason this can't be backported to 2.7 ? No technical reason. I targeted the change at Telly though as I felt it was a bit experimental at the time (over a year ago) and it felt like a feature. We do have one bug (#14378) open against it which is waiting to be merged. -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] why I don't feel that ENCs are very functional right now (performance)
On 12/06/12 11:47, Trevor Vaughan wrote: > 3) Augeas is slower that the native concat type that we posted to > Github (though that needs some polish) Yes, prior to 3.0 it is a lot slower. The reason's simple, it loads and parses every file unless you explicitly tell it (via lens/incl params) which file you intend to edit. 3.0 has an optimisation (#7285) so if you use the context param then it uses this to load only the subset of files matching the context given. This should significantly speed up resources where context is given (usually the case) by eliminating a lot of I/O. -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] Re: Improving Augeas' idempotence in Puppet
On 06/04/12 09:26, Raphaël Pinson wrote: > As of today, the way the Augeas provider in Puppet manages idempotence > can be somehow problematic. The `onlyif` statements can only be > evaluated on the client, so all Augeas resources are generally run on > the client, and whether to run them cannot be easily determined in the > catalog, unless it relies on other resources as dependencies or on > custom facts (possibly using the Augeas ruby library). I agree that idempotency with the Augeas provider is a big problem for users today. I'm not sure that moving the problem completely to the master is the right solution though. If the resource is removed from the catalog if you know it's already in sync (via the idea below) then reports, no-op mode etc will no longer contain any information about it. Dashboard, the Foreman, compliance/auditing functionality will no longer show the resource state. Some users also like the catalog to be more permanent - a feature we're seeing in the Puppet "Telly" faces, where a catalog can more easily be cached and re-run at a later date. Ensuring the state is verified on the client rather than the master makes more sense here. > Here is a proposition to improve this, by making the Augeas tree > available on the Puppet server during catalog compilation. > > A new aug_to_xml() API call has been added in Augeas 0.10.0 allowing > to export the whole (or part of the) Augeas tree as an XML document. > > The idea is the following: > > * Before compiling the catalog, make a request to retrieve the > Augeas tree as XML (using facter or another system); Ken Barber's been working on adding structured data support to Facter, so potentially it could even be transported through this: http://projects.puppetlabs.com/issues/4561 I'd also wonder about the security and sense of sending the contents of every file up as a fact though to be stored, as the dump-xml output of the 741 parsed files here is about 6.7MB. > * On the server, reinject the XML in a local Augeas instance (using > a yet-to-code aug_from_xml() call); > * Evaluate the onlyif statements (or a new kind of statement) using > this local copy of the client's Augeas tree; This is the bit that gets me, I'm not sure that this is an improvement over doing it on the client. You'll still need a way to write the evaluation that's equivalent to the "onlyif" statements in use today. The only way I see it being an improvement was if you then generated the Augeas commands using ERB or similar, based on the tree sent through Facter. You could probably solve most idempotency problems like this, but it'd be rather complex to write. I don't have any solutions at the moment for idempotency. I've been thinking about creating new aug_srun/augtool commands representing more complex operations that could be used in Puppet - things you'd normally do in a proper language via the APIs trivially. David's also suggested this in the past (Puppet issue #2696) to create conditionals in the provider language (complexity I think we should avoid). Christos Bountalis created a config "merging" implementation last year for GSoC which got me wondering if the Puppet resource should instead contain one tree that's merged into the file. Unfortunately the implementation was only designed for simple filetypes and couldn't merge complex trees (I think the data on *how* to merge complex trees is missing in the lens definition). I saw a comment this week from David on R.I.Pienaar's puppet-concat blog entry which shows an idea to write the tree out in the resource itself and then have the provider create it. I think this would be even easier now with hash support in the Puppet DSL. http://www.devco.net/archives/2010/02/19/building_files_from_fragments_with_puppet.php/comment-page-1#comment-5096 Regards, -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Differing behavior between Ruby DSL & Puppet language. Bug?
On 02/12/11 18:27, Jacob Helwig wrote: > So, while looking into Dominic Cleal's patch for #8011[0], I ended > up finding out (thanks to his investigation) that there is a rather > large difference in behavior for parameter/property handling > between the Ruby DSL, and the Puppet language. I think we got into a muddle looking into a spec failure - I don't think any difference exists. Thanks for the catalog comparison tip Nick, I tried this out and indeed couldn't see any difference in the representation. Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] ANNOUNCE: Facter 1.6.1rc2
On 09/09/11 01:18, Matthaus Litteken wrote: > Facter 1.6.1rc2 is a maintenance release containing fixes, updates and > refactoring. Significant effort has been put into getting to Facter to > run on Windows for this release, as noted below. Could we please see the fix for #8491 included in 1.6.1? I think it's a bad regression from 1.5.x to 1.6.0: (#8461) "Stack level too deep" when unknown fact is requested Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Pulling the trigger on using GitHub Pull Requests for patch submission (and internal development).
On 03/08/11 01:57, Jacob Helwig wrote: > The tl;dr: > > Our new preferred method of contributing changes is via GitHub pull > requests, and all Puppet Labs developers will be submitting their > changes for inclusion into the repository via pull request. > > We will still be accepting changes via `rake mail_patches`, > git-format-patch(1) & git-send-email(1), and attaching diffs to > Redmine tickets, though these are not the preferred method. Is it best for outstanding patches to be resubmitted via pull requests to ensure they're tracked and reviewed? -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/facter 3/3] (#2157) Adding support for non-ruby files
On 13/07/11 08:46, Luke Kanies wrote: > This primarily takes Volcane's code[1], adds tests, and > splits it into multiple files. > > It has support for facts in non-ruby files, using either plain test, > json, or yaml. You can also have a script that returns facts on > execution. Very nice, this will be useful. I'd thought of this as something for the proposed Facter 2.0 redesign. Will other patches for 2.x targeted features be considered for 1.x now? (Personally, I'd love to see something to fix #2066 included). > Things of note: > > * We're defaulting to /etc/facts.d, just like the original code. The > ticket calls for this to be /etc/facter.d. I'd agree with the ticket here, it'd be better to have the product name in the path as it'll no doubt be needed later for other configuration. For executable scripts, they should probably be sitting under /usr/share or lib - perhaps even symlinked back to /etc (Munin does something similar from memory). > * We're defaulting to a cache file in /tmp rather than, say, /var/tmp. > This is probably fine, but worthy of note. Not particularly keen on this - the cache should really be somewhere that isn't world-writeable, such as /var/cache/facter. Could there be attacks where an unprivileged user writes to /tmp/facts_cache.yaml and Facter (running as root, remember) loads it, deserialising a dangerous Ruby object inside? It seems to simply let untrusted data enter a privileged Facter process. Similarly, there might be symlink attacks when writing to the file under /tmp. > * There's no way to turn this off or configure any of this at this > point. I think some sort of configuration might be needed very soon, just to make packaging for different distributions easier. At the very least, OpenCSW is going to change these paths and this will require patching. In Puppet, it's trivial to change all of the different cache and configuration directories (vardir etc.) to other locations. Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/facter 1/1] (#7854) Add Augeas library version fact
Add fact to return the Augeas version from /augeas/version. Requires the
ruby-augeas binding.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/7854
lib/facter/augeasversion.rb | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 lib/facter/augeasversion.rb
diff --git a/lib/facter/augeasversion.rb b/lib/facter/augeasversion.rb
new file mode 100644
index 000..481b46d
--- /dev/null
+++ b/lib/facter/augeasversion.rb
@@ -0,0 +1,29 @@
+# Fact: augeasversion
+#
+# Purpose: Report the version of the Augeas library
+#
+# Resolution:
+# Loads ruby-augeas and reports the value of /augeas/version, the version of
+# the underlying Augeas library.
+#
+# Caveats:
+# The library version may not indicate the presence of certain lenses,
+# depending on the system packages updated, nor the version of ruby-augeas
+# which may affect support for the Puppet Augeas provider.
+# Versions prior to 0.3.6 cannot be interrogated for their version.
+#
+
+Facter.add(:augeasversion) do
+ setcode do
+begin
+ require 'augeas'
+ aug = Augeas::open('/', nil, Augeas::NO_MODL_AUTOLOAD)
+ ver = aug.get('/augeas/version')
+ aug.close
+ ver
+rescue Exception
+ Facter.debug('ruby-augeas not available')
+end
+ end
+end
+
--
1.7.4.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 1/1] (#8011) Support temp repo URLs in pkgutil provider
One or more URLs to pkgutil repositories can be supplied in the "source"
attribute and are given to pkgutil via the -t option as temporary repos.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/8011
lib/puppet/provider/package/pkgutil.rb | 45 ++---
spec/unit/provider/package/pkgutil_spec.rb | 72
2 files changed, 90 insertions(+), 27 deletions(-)
diff --git a/lib/puppet/provider/package/pkgutil.rb
b/lib/puppet/provider/package/pkgutil.rb
index a1d844f..c4fd913 100755
--- a/lib/puppet/provider/package/pkgutil.rb
+++ b/lib/puppet/provider/package/pkgutil.rb
@@ -39,7 +39,8 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
:sun, :source => :sun d
# The -c pkglist lists installed packages
pkginsts = []
-pkglist(hash).each do |pkg|
+output = pkguti(["-c"])
+parse_pkglist(output).each do |pkg|
pkg.delete(:avail)
pkginsts << new(pkg)
@@ -72,19 +73,17 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
:sun, :source => :sun d
end.reject { |h| h.nil? }
end
- # Turn our pkgutil -c listing into a bunch of hashes.
- # Supports :justme => packagename, which uses the optimised --single arg
- def self.pkglist(hash)
-command = ["-c"]
-
-if hash[:justme]
- # The --single option speeds up the execution, because it queries
- # the package managament system for one package only.
- command << "--single"
- command << hash[:justme]
-end
+ # Turn our pkgutil -c listing into a hash for a single package.
+ def pkgsingle(resource)
+# The --single option speeds up the execution, because it queries
+# the package managament system for one package only.
+command = ["-c", "--single", resource[:name]]
+self.class.parse_pkglist(run_pkgutil(resource, command), { :justme =>
resource[:name] })
+ end
-output = pkguti(command).split("\n")
+ # Turn our pkgutil -c listing into a bunch of hashes.
+ def self.parse_pkglist(output, hash = {})
+output = output.split("\n")
if output[-1] == "Not in catalog"
Puppet.warning "Package not in pkgutil catalog: %s" % hash[:justme]
@@ -146,18 +145,28 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
:sun, :source => :sun d
end
end
+ def run_pkgutil(resource, *args)
+# Allow source to be one or more URLs pointing to a repository that all
+# get passed to pkgutil via one or more -t options
+if resource[:source]
+ pkguti *[resource[:source].map{|src| [ "-t", src ]}, *args].flatten
+else
+ pkguti *args.flatten
+end
+ end
+
def install
-pkguti "-y", "-i", @resource[:name]
+run_pkgutil @resource, "-y", "-i", @resource[:name]
end
# Retrieve the version from the current package file.
def latest
-hash = self.class.pkglist(:justme => @resource[:name])
+hash = pkgsingle(@resource)
hash[:avail] if hash
end
def query
-if hash = self.class.pkglist(:justme => @resource[:name])
+if hash = pkgsingle(@resource)
hash
else
{:ensure => :absent}
@@ -165,11 +174,11 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
:sun, :source => :sun d
end
def update
-pkguti "-y", "-u", @resource[:name]
+run_pkgutil @resource, "-y", "-u", @resource[:name]
end
def uninstall
-pkguti "-y", "-r", @resource[:name]
+run_pkgutil @resource, "-y", "-r", @resource[:name]
end
end
diff --git a/spec/unit/provider/package/pkgutil_spec.rb
b/spec/unit/provider/package/pkgutil_spec.rb
index dcae212..e51add8 100755
--- a/spec/unit/provider/package/pkgutil_spec.rb
+++ b/spec/unit/provider/package/pkgutil_spec.rb
@@ -38,6 +38,20 @@ describe provider do
@provider.expects(:pkguti).with('-y', '-i', 'TESTpkg')
@provider.install
end
+
+it "should support a single temp repo URL" do
+ @resource[:ensure] = :latest
+ @resource[:source] = "http://example.net/repo";
+ @provider.expects(:pkguti).with('-t', 'http://example.net/repo', '-y',
'-i', 'TESTpkg')
+ @provider.install
+end
+
+it "should support multiple temp repo URLs" do
+ @resource[:ensure] = :latest
+ @resource[:source] = [ 'http://example.net/repo',
'http://example.net/foo' ]
+ @provider.expects(:pkguti).with('-t', 'http://example.net/repo', '-t',
'http://example.net/foo', '-y', '-i', 'TESTpkg')
+ @provider.install
+end
end
describe "when updating" do
@@ -45
Re: [Puppet-dev] [PATCH/facter 1/1] Fixed #7307 - Added serial number fact to Solaris
Sorry for the delayed response, bit of a backlog.
On 19/05/11 18:46, Jacob Helwig wrote:
> On Thu, 19 May 2011 09:44:47 +0100, Dominic Cleal wrote:
>>
>> On 19/05/11 06:41, James Turnbull wrote:
>>> +Facter.add('serialnumber') do
>>> + setcode do
>>> +Facter::Util::Resolution.exec("/usr/sbin/sneep")
>>> + end
>>> +end
>>
>> The only trouble with this is that sneep isn't shipped with the OS and
>> is an extra support tool, but I believe it's the only standard way of
>> doing the job.
>>
>> You can read it out with /usr/sbin/eeprom, having written it to the
>> nvram in the past with sneep. I think having sneep seems a sensible
>> dependency to me though.
>>
>> +1 from me.
>
> I'm +1 to this as well assuming that the output of sneep without any
> arguments is appropriate for use in a fact (I haven't seen the output
> myself, but trust you've checked).
Yes, it just outputs the serial number on stdout.
> It might be worth looking into supporting using eeprom directly if sneep
> isn't found. The sneep FAQ[1] seems to indicate that sneep isn't
> actually needed for either reading or writing the serial number.
Indeed, you can use eeprom to read it back out... something like:
output = Facter::Util::Resolution.exec("/usr/sbin/eeprom")
output.each{|line| serial = $1 if line =~ /ChassisSerialNumber\s+(\S+)/}
This would help me to be honest, as it's common for the serial to have
been set but sneep isn't always available to read it.
The style is just a convention used by sneep rather than anything else,
so it works for most cases.
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7818 512168
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Package type: enable/disable repo vs options (#2247 vs #4113)
On 02/06/11 18:16, Jacob Helwig wrote: > We currently have to feature requests to add similar (or at least > overlapping) functionality to the Package type. > > #2247[1] - enablerepo and disablerepo for yum type > > #4113[2] - Provide a generic "options"-style parameter for packages. > > It seems like having #4113 would remove the need for having #2247, but I > wanted to get some wider opinions to make sure I wasn't ignoring some > use-case that would make this not the case. The only use case I can't see being solved with #4113, is support for selecting a repo with the zypper package provider. It selects a repo by running "zypper install repo:package" (as I understand it), rather than as a separate command line option. > Personally, I think we should move forward on #4113 instead of #2247, > since #4113 seems like the more general solution, and isn't tied > directly to the yum provider. I'd prefer to see both. I don't think #2247 needs to be tied to yum as the same notion of selecting the source repository(s) applies to four other providers[1], not to mention the others that already have this ability via the "source" attribute to select a repository by URL. The difficulty might be how to design it so that it's generic enough, rather than using attributes named enablerepo and disablerepo (which I dislike, because they're so very yum-specific). I have a more detailed suggestion I can outline in another post.. [1] http://projects.puppetlabs.com/issues/2247#note-36 -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/facter 1/1] Fixed #7307 - Added serial number fact to Solaris
On 19/05/11 06:41, James Turnbull wrote:
> +Facter.add('serialnumber') do
> + setcode do
> +Facter::Util::Resolution.exec("/usr/sbin/sneep")
> + end
> +end
The only trouble with this is that sneep isn't shipped with the OS and
is an extra support tool, but I believe it's the only standard way of
doing the job.
You can read it out with /usr/sbin/eeprom, having written it to the
nvram in the past with sneep. I think having sneep seems a sensible
dependency to me though.
+1 from me.
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7818 512168
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Re: (#2728) Utilise Augeas SAVE_NEWFILE mode to provide a diff of any changes that augeas will make.
On 17/05/11 08:14, Michael Knox wrote: > Thanks, > I've updated my branch based on comments, and it works fine with a dummy > manifest that includes a single file change, changes to multiple files > and changes to a file with an alternative root. Also cherry-picked > Dominic's initial test cases. > > https://github.com/mikeknox/puppet/tree/feature/master/2728 Good work. Did you get a chance to look at my comments from the 28th? Just a couple of small things to keep it inline with the file provider. > But now I'm having a crash course in mocha/rspec test cases... > Most of the existing tests still pass except for the "augeas execution > integration" tests which now fail. > > I've made some updates, but it feels like the tests are too perscriptive > about how the provider is working internally rather than what it's > results should be. Yeah, they're very prescriptive because the entire Augeas type is stubbed, rather than being a "real" resource object. The pattern for specs has changed and it'd be good to get the test harness rewritten to follow the new style... probably best to file a new bug and perhaps somebody will pick it up. > I'm quite concerned that I need to be digging in the "augeas execution > integration" tests, but they seem to be quite sensitive to the changes > I've made in the provider. > > Does anybody have some suggestions on this? Try this patch instead: https://gist.github.com/979650 The /augeas/events/saved match is stubbed at the whole group of tests level so you don't need to mess with all of those tests. It's still a bit invasive, but the best you can really do with the file like it is I think. Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 1/1] (#7285) Use Augeas NO_LOAD/incl to optimise loading based on context
When the context property is given, use the NO_LOAD flag to stop Augeas loading
all files for all lenses. Scan the /augeas/load//incl nodes to find those
relevant to the context given and then remove all others before loading.
This speeds up loading when the context is provided, as Augeas only reads and
parses relevant files, instead of every known file for each resource.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/7285
lib/puppet/provider/augeas/augeas.rb | 55 +-
spec/unit/provider/augeas/augeas_spec.rb | 49 ++
2 files changed, 103 insertions(+), 1 deletions(-)
diff --git a/lib/puppet/provider/augeas/augeas.rb
b/lib/puppet/provider/augeas/augeas.rb
index a16f54b..85dd6df 100644
--- a/lib/puppet/provider/augeas/augeas.rb
+++ b/lib/puppet/provider/augeas/augeas.rb
@@ -138,7 +138,14 @@ Puppet::Type.type(:augeas).provide(:augeas) do
unless @aug
flags = Augeas::NONE
flags = Augeas::TYPE_CHECK if resource[:type_check] == :true
- flags |= Augeas::NO_MODL_AUTOLOAD if resource[:incl]
+
+ if resource[:incl]
+flags |= Augeas::NO_MODL_AUTOLOAD
+ elsif resource[:context] and resource[:context].match("^/files/.*")
+# Optimise loading if the context is given
+flags |= Augeas::NO_LOAD
+ end
+
root = resource[:root]
load_path = resource[:load_path]
debug("Opening augeas with root #{root}, lens path #{load_path}, flags
#{flags}")
@@ -150,6 +157,27 @@ Puppet::Type.type(:augeas).provide(:augeas) do
aug.set("/augeas/load/Xfm/lens", resource[:lens])
aug.set("/augeas/load/Xfm/incl", resource[:incl])
aug.load
+ elsif resource[:context] and resource[:context].match("^/files/")
+ctx_path = resource[:context].sub("/files", "")
+
+# Use the context to identify all 'incl' nodes with globs that match
+# the file we're editing.
+incl_paths = {}
+aug.match("/augeas/load//incl").each do |incl_augp|
+ incl_path = aug.get(incl_augp)
+ incl_paths[incl_augp] = incl_path if incl_path and
glob_matches?(incl_path, ctx_path)
+end
+
+# Remove all incl nodes and add back the ones known to be appropriate
+unless incl_paths.empty?
+ aug.rm("/augeas/load//incl")
+ incl_paths.each { |incl_augp,incl_path|
+aug.set("%s[last()+1]" % incl_augp, incl_path)
+ }
+else
+ debug("Augeas optimisation failed, unable to find #{ctx_path} in
/augeas/load//incl")
+end
+aug.load
end
end
@aug
@@ -163,6 +191,31 @@ Puppet::Type.type(:augeas).provide(:augeas) do
end
end
+ # Test if a glob from Augeas' incl nodes matches a given context path.
+ # Supporting full glob capabilities (a la POSIX, man 7 glob) is tricky and
+ # not used in Augeas yet.
+ def glob_matches?(glob, path)
+glob = glob.gsub("*", ".*").gsub("?", ".")
+rglob = Regexp.new(/^#{glob}$/)
+cpath = path
+
+# The context path may be more specific than the glob, so strip off the
last
+# path component until it matches
+until cpath.empty?
+ return true if rglob.match(cpath)
+ cpath = cpath.sub(/\/[^\/]*$/, '')
+end
+
+# If the context path is less specific (e.g. /files/etc/sysconfig) then
+# also match globs for files beneath this path
+until glob.empty? or glob == "~"
+ return true if rglob.match(path)
+ glob = glob.sub(/\/[^\/]*$/, '')
+ rglob = Regexp.new(/^#{glob}$/)
+end
+false
+ end
+
# Used by the need_to_run? method to process get filters. Returns
# true if there is a match, false if otherwise
# Assumes a syntax of get /files/path [COMPARATOR] value
diff --git a/spec/unit/provider/augeas/augeas_spec.rb
b/spec/unit/provider/augeas/augeas_spec.rb
index 5bb98ea..a1928c9 100755
--- a/spec/unit/provider/augeas/augeas_spec.rb
+++ b/spec/unit/provider/augeas/augeas_spec.rb
@@ -487,4 +487,53 @@ describe provider_class do
@provider.execute_changes.should == :executed
end
end
+
+ describe "incl glob matching" do
+before do
+ @resource = stub("resource")
+ @provider = provider_class.new(@resource)
+end
+
+it "should match identical path" do
+ glob = "/etc/sysconfig/network"
+ path = "/etc/sysconfig/network"
+ @provider.glob_matches?(glob, path).should == true
+end
+
+it "should match path with trailing slash" do
+ glob = "/etc/sysconfig/network"
+ path = "/etc/sysconfig/network/"
+ @provider.glob_matches?(glob, path).should == true
+end
+
+it "should match simple * glob" do
+
Re: [Puppet-dev] Re: (#2728) Utilise Augeas SAVE_NEWFILE mode to provide a diff of any changes that augeas will make.
On 27/04/11 05:56, Mike wrote: > I'm guessing that this has slipped through a filter somewhere, but I'm > hoping it could be reviewed and included soon. Apologies Mike, I've been waiting for a chance. Now I'm at Puppet Camp, I have free time on my hands :-) Comments inline: >> +saved_files.each do |tmp_file| >> + saved_file = tmp_file.sub(/^\/files/, '') >> + info(diff(saved_file, saved_file + ".augnew")) >> + if Puppet[:noop] >> +File.delete(saved_file + ".augnew") >> + end >> +end This diff works slightly differently to the file type, could they be made consistent? See lib/puppet/type/file/content.rb. Specifically, the file type checks the show_diff setting and uses "print" instead of "info". >> ensure >> - close_augeas >> + if Puppet[:noop] >> +close_augeas >> + end >> end The close_augeas method should also be called when no files are changed (return_value is false) or when in noop. Also when checking noop, it should check the resource noop? method which checks the resource's noop attribute and the global setting. I'd suggest this: if not return_value or resource.noop? close_augeas end Otherwise works and looks great - thanks for patching it! Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 1/1] (#6845) Mount writes incorrect vfstab entries
+1, spec now passes on Solaris (no "live" testing). On 25/03/11 07:43, Stefan Schulte wrote: > Facter[:operatingsystem] will not retrieve the operatingsystem as a > string so puppet will always write fstab entries. > > Signed-off-by: Stefan Schulte > --- > lib/puppet/provider/mount/parsed.rb |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/lib/puppet/provider/mount/parsed.rb > b/lib/puppet/provider/mount/parsed.rb > index 11c5e21..7c3f41b 100755 > --- a/lib/puppet/provider/mount/parsed.rb > +++ b/lib/puppet/provider/mount/parsed.rb > @@ -18,7 +18,7 @@ Puppet::Type.type(:mount).provide( > >commands :mountcmd => "mount", :umount => "umount" > > - case Facter["operatingsystem"] > + case Facter.value(:operatingsystem) >when "Solaris" > @fields = [:device, :blockdevice, :name, :fstype, :pass, :atboot, > :options] >else -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Run specs on Solaris with 2.6.7
On 01/04/11 19:16, Stefan Schulte wrote: > Can someone please run > > rspec -c --format s spec/unit/provider/mount/parsed_spec.rb > > on a Solaris machine against puppet 2.6.7? Sure, here's the test summary: Puppet::Type::Mount::ProviderParsed should default to /etc/vfstab on Solaris should default to /etc/fstab on anything else (PENDING: This test does not work on Solaris) when parsing a line should not crash on incomplete lines in fstab on Solaris should extract device from the first field should extract blockdevice from second field (FAILED - 1) should extract name from third field (FAILED - 2) should extract fstype from fourth field (FAILED - 3) should extract pass from fifth field (FAILED - 4) should extract atboot from sixth field (FAILED - 5) should extract options from seventh field (FAILED - 6) on other platforms than Solaris mountinstances should get name from mountoutput found on Solaris should get name from mountoutput found on HP-UX should get name from mountoutput found on Darwin should get name from mountoutput found on Linux should get name from mountoutput found on AIX should raise an error if a line is not understandable when prefetching should set :ensure to :unmounted if found in fstab but not mounted (FAILED - 7) should set :ensure to :mounted if found in fstab and mounted should set :ensure to :ghost if not found in fstab but mounted (FAILED - 8) should set :ensure to :absent if not found in fstab and not mounted Pending: Puppet::Type::Mount::ProviderParsed should default to /etc/fstab on anything else # This test does not work on Solaris # ./spec/unit/provider/mount/parsed_spec.rb:64 Full output: http://pastie.org/1747266 > John Warburton reported a serious bug #6845 where puppet parses > /etc/vfstab on Solaris like an /etc/fstab file. This may also destroy > your whole file since /etc/fstab has less fields than /etc/vfstab. > > The bug was introduced in ade951a (I feel bad now) but there are specs > that should have detected the bug (I feel a bit better now). > Unfortunately these tests do only run on Solaris so I never saw any > failures. Can someone please run the specs on Solaris so I know that they > are working? > > I already sent a patch to fix the issue to puppet-dev. I've applied the patch from your -dev e-mail to the plain 2.6.7 checkout and the spec now passes: Finished in 0.09687 seconds 20 examples, 0 failures, 1 pending -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 23/23] (#4258) Bug fix: populating instances for aliases
On 21/03/11 11:50, Dominic Cleal wrote: > On 21/03/11 09:08, Dominic Cleal wrote: >> On 21/03/11 03:54, Juerg Walz wrote: >>> diff --git a/lib/puppet/provider/package/pkgutil.rb >>> b/lib/puppet/provider/package/pkgutil.rb >>> index 350cacc..97625f2 100755 >>> --- a/lib/puppet/provider/package/pkgutil.rb >>> +++ b/lib/puppet/provider/package/pkgutil.rb >>> @@ -38,7 +38,7 @@ Puppet::Type.type(:package).provide :pkgutil, :parent => >>> :sun, :source => :sun d >>># Create a second instance with the alias if it's different >>>pkgalias = aliases[pkg[:name]] >>>if pkgalias and pkg[:name] != pkgalias >>> -apkg = Hash.new(pkg) >>> +apkg = pkg >>> apkg[:name] = pkgalias >>> pkginsts << new(apkg) >>>end >> >> Thanks for the testing - what issue did you run into with this? > > Sorry, just saw the "cover note" on the patch set that explained it. > Perhaps we should be doing pkg.dup here - not sure where I got the > Hash.new bit from, I'd intended to duplicate it. Yep, fixed with pkg.dup. > As below though, I'll do a bit more testing later to see exactly what > the issue was and try and capture it in a test before changing it again. It was causing the main package names to be queried each time, perhaps as a reference to the hash is kept internally to the provider instance, so we were modifying the same one. I couldn't see an obvious way to test for this. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/facter 1/2] (#2714) Added timeout to prtdiag resulution
On 22/03/11 20:05, Adrien Thebo wrote: > - prtdiag would hang in specific cases, subsequently hanging facter. >This should kill prtdiag if it takes excessively long. I added a call to prtdiag in the manufacturer/product facts (only for SPARC), so it might be worth updating util/manufacturer.rb too with this fix. Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 23/23] (#4258) Bug fix: populating instances for aliases
On 21/03/11 09:08, Dominic Cleal wrote: > Hi Juerg, > > On 21/03/11 03:54, Juerg Walz wrote: >> >> Signed-off-by: Juerg Walz >> --- >> Local-branch: tickets/master/4258-dev >> lib/puppet/provider/package/pkgutil.rb |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/lib/puppet/provider/package/pkgutil.rb >> b/lib/puppet/provider/package/pkgutil.rb >> index 350cacc..97625f2 100755 >> --- a/lib/puppet/provider/package/pkgutil.rb >> +++ b/lib/puppet/provider/package/pkgutil.rb >> @@ -38,7 +38,7 @@ Puppet::Type.type(:package).provide :pkgutil, :parent => >> :sun, :source => :sun d >># Create a second instance with the alias if it's different >>pkgalias = aliases[pkg[:name]] >>if pkgalias and pkg[:name] != pkgalias >> -apkg = Hash.new(pkg) >> +apkg = pkg >> apkg[:name] = pkgalias >> pkginsts << new(apkg) >>end > > Thanks for the testing - what issue did you run into with this? Sorry, just saw the "cover note" on the patch set that explained it. Perhaps we should be doing pkg.dup here - not sure where I got the Hash.new bit from, I'd intended to duplicate it. As below though, I'll do a bit more testing later to see exactly what the issue was and try and capture it in a test before changing it again. > I'd > started with something similar (that is, just changing :name in pkg and > supplying that to 'new') but when using it for real in Puppet, I think > it broke cases where using the full package name (CSWsvn) when an alias > was present (subversion). > > I'll go back and test both cases at some point and perhaps we can create > a test to show the issue. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 1/1] (#2728) Add diff output for changes made by Augeas provider
On 21/03/11 04:00, Michael Knox wrote: > On 21/03/11 2:22 PM, Daniel Pittman wrote: >> On Sun, Mar 20, 2011 at 15:31, Michael >> Knox wrote: >>> On 21/03/11 5:56 AM, Daniel Pittman wrote: >>> Am I correct in understanding that we are writing a temporary copy >>> for the >>> diff, then rewriting the change to the real file separately? >>> >>> Yes >>> >>> If so, could we instead use "rename" to avoid the costly parse/write >>> cycle being run twice per file? >>> >>> Probably, my concern would be the maintenance of file permissions, >>> timestamps etc. >>> I'll have a look and see about reworking the patch to do a "rename" >> >> I kind of assumed that Augeus would do that for us, because it makes >> sense if they have a "write a new file" mode that it would by default >> match the old file. If not ... well, I guess either way would be >> fine, but I wouldn't fight to have it use rename if it was more >> complex. :) Augeas does preserve file permissions when creating the .augnew file, so a rename make sense. Under the covers when in NOOP or not, Augeas does write out the .augnew file and then compares them to determine whether modifying the tree actually had an effect or not. If it's not in NOOP, it then does a rename back to the original filename (or copies the contents if that fails). So based on the current implementation of Augeas's NOOP mode, the cost of an operation would be the same. > Not in the Augeas's 4 save modes, noop, newfile, backup & overwrite. I > have a half written patch which does a rename of .augnew exists > when executing the changes, but it's beginning to look quite complex (in > comparison) and ugly. If you can do the rename in the execute_changes from the .augnew generated in the need_to_run (within Daniel's bounds of not making it horrible!), I think you'd be making it more efficient and more consistent with Augeas itself. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 23/23] (#4258) Bug fix: populating instances for aliases
Hi Juerg, On 21/03/11 03:54, Juerg Walz wrote: > > Signed-off-by: Juerg Walz > --- > Local-branch: tickets/master/4258-dev > lib/puppet/provider/package/pkgutil.rb |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/lib/puppet/provider/package/pkgutil.rb > b/lib/puppet/provider/package/pkgutil.rb > index 350cacc..97625f2 100755 > --- a/lib/puppet/provider/package/pkgutil.rb > +++ b/lib/puppet/provider/package/pkgutil.rb > @@ -38,7 +38,7 @@ Puppet::Type.type(:package).provide :pkgutil, :parent => > :sun, :source => :sun d ># Create a second instance with the alias if it's different >pkgalias = aliases[pkg[:name]] >if pkgalias and pkg[:name] != pkgalias > -apkg = Hash.new(pkg) > +apkg = pkg > apkg[:name] = pkgalias > pkginsts << new(apkg) >end Thanks for the testing - what issue did you run into with this? I'd started with something similar (that is, just changing :name in pkg and supplying that to 'new') but when using it for real in Puppet, I think it broke cases where using the full package name (CSWsvn) when an alias was present (subversion). I'll go back and test both cases at some point and perhaps we can create a test to show the issue. Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 2/2] (#4258) Use pkgutil -a to reliably determine package common names/aliases
Populate instances with both the real package name ("CSWsvn") and the alias
name ("subversion") from separate "pkgutil -a" call.
Fixed cases where pkgutil noise was parsed as aliased package names and also
breaking "not in catalog" detection.
Updated pkgutil_spec test to show various edge cases.
Signed-off-by: Dominic Cleal
---
lib/puppet/provider/package/pkgutil.rb | 86 ---
spec/unit/provider/package/pkgutil_spec.rb | 60 +--
2 files changed, 117 insertions(+), 29 deletions(-)
diff --git a/lib/puppet/provider/package/pkgutil.rb
b/lib/puppet/provider/package/pkgutil.rb
index 3a23796..350cacc 100755
--- a/lib/puppet/provider/package/pkgutil.rb
+++ b/lib/puppet/provider/package/pkgutil.rb
@@ -23,10 +23,45 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
:sun, :source => :sun d
end
def self.instances(hash = {})
-pkglist(hash).collect do |bhash|
- bhash.delete(:avail)
- new(bhash)
+# Use the available pkg list (-a) to work out aliases
+aliases = {}
+availlist.each do |pkg|
+ aliases[pkg[:name]] = pkg[:alias]
end
+
+# The -c pkglist lists installed packages
+pkginsts = []
+pkglist(hash).each do |pkg|
+ pkg.delete(:avail)
+ pkginsts << new(pkg)
+
+ # Create a second instance with the alias if it's different
+ pkgalias = aliases[pkg[:name]]
+ if pkgalias and pkg[:name] != pkgalias
+apkg = Hash.new(pkg)
+apkg[:name] = pkgalias
+pkginsts << new(apkg)
+ end
+end
+
+pkginsts
+ end
+
+ # Turns a pkgutil -a listing into hashes with the common alias, full
+ # package name and available version
+ def self.availlist
+output = pkguti ["-a"]
+
+list = output.split("\n").collect do |line|
+ next if line =~ /^common\s+package/ # header of package list
+ next if noise?(line)
+
+ if line =~ /\s*(\S+)\s+(\S+)\s+(.*)/
+{ :alias => $1, :name => $2, :avail => $3 }
+ else
+Puppet.warning "Cannot match %s" % line
+ end
+end.reject { |h| h.nil? }
end
# Turn our pkgutil -c listing into a bunch of hashes.
@@ -41,36 +76,45 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
:sun, :source => :sun d
command << hash[:justme]
end
-output = pkguti command
+output = pkguti(command).split("\n")
-list = output.split("\n").collect do |line|
- next if line =~ /^#/
+if output[-1] == "Not in catalog"
+ Puppet.warning "Package not in pkgutil catalog: %s" % hash[:justme]
+ return nil
+end
+
+list = output.collect do |line|
next if line =~ /installed\s+catalog/ # header of package list
- next if line =~ /^Checking integrity / # use_gpg
- next if line =~ /^gpg: / # gpg verification
- next if line =~ /^=+> /# catalog fetch
- next if line =~ /\d+:\d+:\d+ URL:/ # wget without -q
+ next if noise?(line)
- pkgsplit(line, hash[:justme])
+ pkgsplit(line)
end.reject { |h| h.nil? }
if hash[:justme]
- # Ensure we picked up the package line, not any pkgutil noise.
- list.reject! { |h| h[:name] != hash[:justme] }
- return list[-1]
+ # Single queries may have been for an alias so return the name requested
+ if list.any?
+list[-1][:name] = hash[:justme]
+return list[-1]
+ end
else
list.reject! { |h| h[:ensure] == :absent }
return list
end
+ end
+ # Identify common types of pkgutil noise as it downloads catalogs etc
+ def self.noise?(line)
+true if line =~ /^#/
+true if line =~ /^Checking integrity / # use_gpg
+true if line =~ /^gpg: / # gpg verification
+true if line =~ /^=+> /# catalog fetch
+true if line =~ /\d+:\d+:\d+ URL:/ # wget without -q
+false
end
# Split the different lines into hashes.
- def self.pkgsplit(line, justme)
-if line == "Not in catalog"
- Puppet.warning "Package not in pkgutil catalog: %s" % justme
- return nil
-elsif line =~ /\s*(\S+)\s+(\S+)\s+(.*)/
+ def self.pkgsplit(line)
+if line =~ /\s*(\S+)\s+(\S+)\s+(.*)/
hash = {}
hash[:name] = $1
hash[:ensure] = if $2 == "notinst"
@@ -80,10 +124,6 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
:sun, :source => :sun d
end
hash[:avail] = $3
- if justme
-hash[:name] = justme
- end
-
if hash[:avail] =~ /^SAME\s*$/
hash[:avail] = hash[:ensure]
end
diff --git a/spec/unit/provider/package/pkgutil_spec.rb
b/spec/unit/provider/package/pkgutil_spec.rb
index 01142b4..4f0e0cc 100755
--- a/spec/unit/provider/package/pkgutil_spec.rb
+++ b/spec/unit/provider/pack
[Puppet-dev] [PATCH/puppet 1/2] (#4258) Update pkgutil spec for recent impl changes
Fix test output of pkgutil for commands using --single
Fix expected upgrade command to match impl
Signed-off-by: Dominic Cleal
---
spec/unit/provider/package/pkgutil_spec.rb | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/spec/unit/provider/package/pkgutil_spec.rb
b/spec/unit/provider/package/pkgutil_spec.rb
index 10cebfe..01142b4 100755
--- a/spec/unit/provider/package/pkgutil_spec.rb
+++ b/spec/unit/provider/package/pkgutil_spec.rb
@@ -37,7 +37,7 @@ describe provider do
describe "when updating" do
it "should use a command without versioned package" do
- @provider.expects(:pkguti).with('-y', '-i', 'TESTpkg')
+ @provider.expects(:pkguti).with('-y', '-u', 'TESTpkg')
@provider.update
end
end
@@ -52,24 +52,22 @@ describe provider do
describe "when getting latest version" do
it "should return TESTpkg's version string" do
fake_data = "
-CSWsvn1.4.5,REV=2007.11.18 SAME
-TESTpkg 1.4.5,REV=2007.11.18 1.4.5,REV=2007.11.20
-CSWemacs notinst 22.1"
+noisy output here
+TESTpkg 1.4.5,REV=2007.11.18 1.4.5,REV=2007.11.20"
provider.expects(:pkguti).with(['-c', '--single', 'TESTpkg']).returns
fake_data
@provider.latest.should == "1.4.5,REV=2007.11.20"
end
it "should handle TESTpkg's 'SAME' version string" do
fake_data = "
-CSWsvn1.4.5,REV=2007.11.18 SAME
-TESTpkg 1.4.5,REV=2007.11.18 SAME
-CSWemacs notinst 22.1"
+noisy output here
+TESTpkg 1.4.5,REV=2007.11.18 SAME"
provider.expects(:pkguti).with(['-c', '--single', 'TESTpkg']).returns
fake_data
@provider.latest.should == "1.4.5,REV=2007.11.18"
end
it "should handle a non-existent package" do
- fake_data = "CSWsvn 1.4.5,REV=2007.11.18 SAME"
+ fake_data = "noisy output here"
provider.expects(:pkguti).with(['-c', '--single', 'TESTpkg']).returns
fake_data
@provider.latest.should == nil
end
@@ -90,10 +88,8 @@ gpg: Signature made February 17, 2011 05:27:53 PM GMT using
DSA key ID E12E9D2F
gpg: Good signature from \"Distribution Manager \"
==> 2770 packages loaded from
/var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.11
package installed catalog
-TESTpkg 1.4.5,REV=2007.11.18 1.4.5,REV=2007.11.20
-testingnoise
-testing noise again"
- provider.expects(:pkguti).returns fake_data
+TESTpkg 1.4.5,REV=2007.11.18 1.4.5,REV=2007.11.20"
+ provider.expects(:pkguti).with(['-c', '--single', 'TESTpkg']).returns
fake_data
@provider.latest.should == "1.4.5,REV=2007.11.20"
end
end
@@ -112,7 +108,7 @@ testing noise again"
end
it "should handle a non-existent package" do
- fake_data = "CSWsvn 1.4.5,REV=2007.11.18 SAME"
+ fake_data = "noisy output here"
provider.expects(:pkguti).with(['-c', '--single', 'TESTpkg']).returns
fake_data
@provider.query[:ensure].should == :absent
end
--
1.7.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Re: [PATCH/puppet 19/19] (#4258) pkgutil provider: better handling of short package names
On 15/03/11 13:24, Dominic Cleal wrote: > On 10/03/11 08:03, Juerg Walz wrote: >> Thanks for the feedback, Dominic. >> I've never actually ran it with debugging turned on (again, I'm fairly >> new to Puppet, and Ruby). I need to read up on the prefetching and >> what's expected in the alias. My mods up to now were mostly trial-and- >> error... >> >> BTW I've just changed that bit of code to handle the case where the >> shortname is different to the package filename. > > Yep, thanks. That should now stop Puppet querying pkgutil for all long > names though it's still going to make extra queries for short names. I > think this is pretty much unavoidable unless pkgutil can output both > long names and short names. A discussion started on -users about the state of the provider, which made me realise some of the tests in the spec weren't passing with these changes. I've taken a closer look this evening and realised that the change to assume lines from -c were aliases of other packages was problematic when pkgutil downloads catalogs etc. What I've now done is to call -a as well as -c to prefetch the package instances, which gives us the aliased name as well as the full package name. With this we can create two instances, one for each name with the same information. This means we no longer have to call out to pkgutil -c --single for every package resource that uses an alias instead of the full package name. The provider should be much more robust now as I've added a few more tests to cope with the edge cases. I'll send the extra commits to the list now, they're also here: https://github.com/domcleal/puppet/tree/tickets/master/4258-dev -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] Re: [PATCH/puppet 19/19] (#4258) pkgutil provider: better handling of short package names
On 10/03/11 08:03, Juerg Walz wrote: > Thanks for the feedback, Dominic. > I've never actually ran it with debugging turned on (again, I'm fairly > new to Puppet, and Ruby). I need to read up on the prefetching and > what's expected in the alias. My mods up to now were mostly trial-and- > error... > > BTW I've just changed that bit of code to handle the case where the > shortname is different to the package filename. Yep, thanks. That should now stop Puppet querying pkgutil for all long names though it's still going to make extra queries for short names. I think this is pretty much unavoidable unless pkgutil can output both long names and short names. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 19/19] (#4258) pkgutil provider: better handling of short package names
Hi Juerg,
Thanks for the extra patches, comment below.
On 08/03/11 06:10, Juerg Walz wrote:
> Local-branch: tickets/master/4258-dev
> lib/puppet/provider/package/pkgutil.rb |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/lib/puppet/provider/package/pkgutil.rb
> b/lib/puppet/provider/package/pkgutil.rb
> index 0e2056b..4a87932 100755
> --- a/lib/puppet/provider/package/pkgutil.rb
> +++ b/lib/puppet/provider/package/pkgutil.rb
> @@ -56,7 +56,7 @@ Puppet::Type.type(:package).provide :pkgutil, :parent =>
> :sun, :source => :sun d
>
[ snip ]
> + if justme !~ /^[A-Z]+/
> +hash[:name].sub! /^[A-Z]+/, ''
> + end
> +
I'm not sure if this is correct behaviour if we're prefetching resources
as Puppet now has to call out to pkgutil for every long package name
specified. Take this for example:
package { [ "CSWgawk", "less" ]:
ensure => present,
}
It now logs:
debug: Prefetching pkgutil resources for package
debug: Puppet::Type::Package::ProviderPkgutil: Executing
'/opt/csw/bin/pkgutil -c'
debug: Puppet::Type::Package::ProviderPkgutil: Executing
'/opt/csw/bin/pkgutil -c --single CSWgawk'
I've tried setting :alias instead with the short name, but this doesn't
seem to work for prefetched resources. Should we be returning two
different resources while prefetching?
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7818 512168
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 4/4] (#6494) Add setm command to Augeas provider
The Augeas setm command can set the value of multiple nodes in a single
operation. Takes a base path, then a subnode path expression (relative
to the base) and then the value itself.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/6494
lib/puppet/provider/augeas/augeas.rb |5 +
spec/unit/provider/augeas/augeas_spec.rb | 12
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/lib/puppet/provider/augeas/augeas.rb
b/lib/puppet/provider/augeas/augeas.rb
index 110885b..5488c66 100644
--- a/lib/puppet/provider/augeas/augeas.rb
+++ b/lib/puppet/provider/augeas/augeas.rb
@@ -32,6 +32,7 @@ Puppet::Type.type(:augeas).provide(:augeas) do
COMMANDS = {
"set" => [ :path, :string ],
+"setm" => [ :path, :string, :string ],
"rm" => [ :path ],
"clear" => [ :path ],
"mv" => [ :path, :path ],
@@ -338,6 +339,10 @@ Puppet::Type.type(:augeas).provide(:augeas) do
debug("sending command '#{command}' with params
#{cmd_array.inspect}")
rv = aug.set(cmd_array[0], cmd_array[1])
fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (!rv)
+ when "setm"
+debug("sending command '#{command}' with params
#{cmd_array.inspect}")
+rv = aug.setm(cmd_array[0], cmd_array[1], cmd_array[2])
+fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (rv == -1)
when "rm", "remove"
debug("sending command '#{command}' with params
#{cmd_array.inspect}")
rv = aug.rm(cmd_array[0])
diff --git a/spec/unit/provider/augeas/augeas_spec.rb
b/spec/unit/provider/augeas/augeas_spec.rb
index 9f1007a..c65f390 100644
--- a/spec/unit/provider/augeas/augeas_spec.rb
+++ b/spec/unit/provider/augeas/augeas_spec.rb
@@ -475,5 +475,17 @@ describe provider_class do
@augeas.expects(:close)
@provider.execute_changes.should == :executed
end
+
+it "should handle setm commands" do
+ command = ["set test[1]/Jar/Jar Foo","set test[2]/Jar/Jar Bar","setm
test Jar/Jar Binks"]
+ context = "/foo/"
+ @resource.expects(:[]).times(2).returns(command).then.returns(context)
+ @augeas.expects(:set).with("/foo/test[1]/Jar/Jar", "Foo").returns(true)
+ @augeas.expects(:set).with("/foo/test[2]/Jar/Jar", "Bar").returns(true)
+ @augeas.expects(:setm).with("/foo/test", "Jar/Jar",
"Binks").returns(true)
+ @augeas.expects(:save).returns(true)
+ @augeas.expects(:close)
+ @provider.execute_changes.should == :executed
+end
end
end
--
1.7.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 2/4] (#6494) Add defnode command to Augeas provider
Uses Augeas' defnode command which creates a variable pointing to a node,
creating it with 'set' if it doesn't already exist.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/6494
lib/puppet/provider/augeas/augeas.rb |5 +
spec/unit/provider/augeas/augeas_spec.rb | 11 ++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/puppet/provider/augeas/augeas.rb
b/lib/puppet/provider/augeas/augeas.rb
index 89f08ac..59513e3 100644
--- a/lib/puppet/provider/augeas/augeas.rb
+++ b/lib/puppet/provider/augeas/augeas.rb
@@ -37,6 +37,7 @@ Puppet::Type.type(:augeas).provide(:augeas) do
"insert" => [ :string, :string, :path ],
"get" => [ :path, :comparator, :string ],
"defvar" => [ :string, :path ],
+"defnode" => [ :string, :path, :string ],
"match" => [ :path, :glob ],
"size" => [:comparator, :int],
"include" => [:string],
@@ -359,6 +360,10 @@ Puppet::Type.type(:augeas).provide(:augeas) do
debug("sending command '#{command}' with params
#{cmd_array.inspect}")
rv = aug.defvar(cmd_array[0], cmd_array[1])
fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (!rv)
+ when "defnode"
+debug("sending command '#{command}' with params
#{cmd_array.inspect}")
+rv = aug.defnode(cmd_array[0], cmd_array[1], cmd_array[2])
+fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (!rv)
else fail("Command '#{command}' is not supported")
end
rescue SystemExit,NoMemoryError
diff --git a/spec/unit/provider/augeas/augeas_spec.rb
b/spec/unit/provider/augeas/augeas_spec.rb
index a65af99..3d53286 100644
--- a/spec/unit/provider/augeas/augeas_spec.rb
+++ b/spec/unit/provider/augeas/augeas_spec.rb
@@ -444,7 +444,7 @@ describe provider_class do
@provider.execute_changes.should == :executed
end
-it "should pass through augeas defvar variables without context" do
+it "should pass through augeas variables without context" do
command = ["defvar myjar Jar/Jar","set $myjar/Binks 1"]
context = "/foo/"
@resource.expects(:[]).times(2).returns(command).then.returns(context)
@@ -456,5 +456,14 @@ describe provider_class do
@provider.execute_changes.should == :executed
end
+it "should handle defnode commands" do
+ command = "defnode newjar Jar/Jar[last()+1] Binks"
+ context = "/foo/"
+ @resource.expects(:[]).times(2).returns(command).then.returns(context)
+ @augeas.expects(:defnode).with("newjar", "/foo/Jar/Jar[last()+1]",
"Binks").returns(true)
+ @augeas.expects(:save).returns(true)
+ @augeas.expects(:close)
+ @provider.execute_changes.should == :executed
+end
end
end
--
1.7.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 1/4] (#6494) Add defvar command to Augeas provider
Uses Augeas' native defvar command to define variables for certain expressions
that can then be referenced later with $variable.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/6494
lib/puppet/provider/augeas/augeas.rb |5 +
spec/unit/provider/augeas/augeas_spec.rb | 23 +++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/lib/puppet/provider/augeas/augeas.rb
b/lib/puppet/provider/augeas/augeas.rb
index 4619682..89f08ac 100644
--- a/lib/puppet/provider/augeas/augeas.rb
+++ b/lib/puppet/provider/augeas/augeas.rb
@@ -36,6 +36,7 @@ Puppet::Type.type(:augeas).provide(:augeas) do
"clear" => [ :path ],
"insert" => [ :string, :string, :path ],
"get" => [ :path, :comparator, :string ],
+"defvar" => [ :string, :path ],
"match" => [ :path, :glob ],
"size" => [:comparator, :int],
"include" => [:string],
@@ -354,6 +355,10 @@ Puppet::Type.type(:augeas).provide(:augeas) do
debug("sending command '#{command}' with params #{[label, where,
path].inspect}")
rv = aug.insert(path, label, before)
fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (rv == -1)
+ when "defvar"
+debug("sending command '#{command}' with params
#{cmd_array.inspect}")
+rv = aug.defvar(cmd_array[0], cmd_array[1])
+fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (!rv)
else fail("Command '#{command}' is not supported")
end
rescue SystemExit,NoMemoryError
diff --git a/spec/unit/provider/augeas/augeas_spec.rb
b/spec/unit/provider/augeas/augeas_spec.rb
index 9fcc856..a65af99 100644
--- a/spec/unit/provider/augeas/augeas_spec.rb
+++ b/spec/unit/provider/augeas/augeas_spec.rb
@@ -433,5 +433,28 @@ describe provider_class do
@augeas.expects(:close)
@provider.execute_changes.should == :executed
end
+
+it "should handle defvar commands" do
+ command = "defvar myjar Jar/Jar"
+ context = "/foo/"
+ @resource.expects(:[]).times(2).returns(command).then.returns(context)
+ @augeas.expects(:defvar).with("myjar", "/foo/Jar/Jar").returns(true)
+ @augeas.expects(:save).returns(true)
+ @augeas.expects(:close)
+ @provider.execute_changes.should == :executed
+end
+
+it "should pass through augeas defvar variables without context" do
+ command = ["defvar myjar Jar/Jar","set $myjar/Binks 1"]
+ context = "/foo/"
+ @resource.expects(:[]).times(2).returns(command).then.returns(context)
+ @augeas.expects(:defvar).with("myjar", "/foo/Jar/Jar").returns(true)
+ # this is the important bit, shouldn't be /foo/$myjar/Binks
+ @augeas.expects(:set).with("$myjar/Binks", "1").returns(true)
+ @augeas.expects(:save).returns(true)
+ @augeas.expects(:close)
+ @provider.execute_changes.should == :executed
+end
+
end
end
--
1.7.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 3/4] (#6494) Add mv command to Augeas provider
Moves the first node to the position of the second, deleting it and its
children if it already exists.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/6494
lib/puppet/provider/augeas/augeas.rb |6 ++
spec/unit/provider/augeas/augeas_spec.rb | 10 ++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/lib/puppet/provider/augeas/augeas.rb
b/lib/puppet/provider/augeas/augeas.rb
index 59513e3..110885b 100644
--- a/lib/puppet/provider/augeas/augeas.rb
+++ b/lib/puppet/provider/augeas/augeas.rb
@@ -34,6 +34,7 @@ Puppet::Type.type(:augeas).provide(:augeas) do
"set" => [ :path, :string ],
"rm" => [ :path ],
"clear" => [ :path ],
+"mv" => [ :path, :path ],
"insert" => [ :string, :string, :path ],
"get" => [ :path, :comparator, :string ],
"defvar" => [ :string, :path ],
@@ -48,6 +49,7 @@ Puppet::Type.type(:augeas).provide(:augeas) do
COMMANDS["ins"] = COMMANDS["insert"]
COMMANDS["remove"] = COMMANDS["rm"]
+ COMMANDS["move"] = COMMANDS["mv"]
attr_accessor :aug
@@ -364,6 +366,10 @@ Puppet::Type.type(:augeas).provide(:augeas) do
debug("sending command '#{command}' with params
#{cmd_array.inspect}")
rv = aug.defnode(cmd_array[0], cmd_array[1], cmd_array[2])
fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (!rv)
+ when "mv", "move"
+debug("sending command '#{command}' with params
#{cmd_array.inspect}")
+rv = aug.mv(cmd_array[0], cmd_array[1])
+fail("Error sending command '#{command}' with params
#{cmd_array.inspect}") if (rv == -1)
else fail("Command '#{command}' is not supported")
end
rescue SystemExit,NoMemoryError
diff --git a/spec/unit/provider/augeas/augeas_spec.rb
b/spec/unit/provider/augeas/augeas_spec.rb
index 3d53286..9f1007a 100644
--- a/spec/unit/provider/augeas/augeas_spec.rb
+++ b/spec/unit/provider/augeas/augeas_spec.rb
@@ -465,5 +465,15 @@ describe provider_class do
@augeas.expects(:close)
@provider.execute_changes.should == :executed
end
+
+it "should handle mv commands" do
+ command = "mv Jar/Jar Binks"
+ context = "/foo/"
+ @resource.expects(:[]).times(2).returns(command).then.returns(context)
+ @augeas.expects(:mv).with("/foo/Jar/Jar", "/foo/Binks").returns(true)
+ @augeas.expects(:save).returns(true)
+ @augeas.expects(:close)
+ @provider.execute_changes.should == :executed
+end
end
end
--
1.7.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 2/2] (#6324) Add spec for SMF service provider
On 18/02/11 18:26, Luke Kanies wrote: > Thanks a ton for doing this. > > I really only have one comment below, and it's about stubs vs. real objects, > which we've changed our tune on recently. [snip] >> +@resource = stub 'resource' >> +@provider = provider_class.new(@resource) >> + >> +@resource.stubs(:[]).returns(nil) >> +@resource.stubs(:[]).with(:name).returns "/system/myservice" >> +@resource.stubs(:[]).with(:ensure).returns :enabled >> +@resource.stubs(:[]).with(:enable).returns :true >> +@resource.stubs(:name).returns "/system/myservice" >> +@resource.stubs(:ref).returns "Service[/system/myservice]" >> +@provider.stubs(:resource).returns @resource > > We have a bunch of tests that do exactly this (where 'this' is using complete > stubs), but over time we've moved away from it, because it tends to make very > fragile tests. Instead we stick to stubbing either external systems (like > Facter) or systems that muck with the disk or network. > > You should be able to create a normal resource here: > > @resource = Puppet::Type.type(:service).new(:name => "/system/myservice") Sure, thanks for the feedback (Daniel too). I've updated the test to create the resource object directly. That's made it much easier, I'd discovered earlier it was fairly brittle trying to stub the whole thing. While changing the test I found an error message for importing manifests was calling a non-existent method, so that's fixed too and is tested. Commits are here: https://github.com/domcleal/puppet/tree/tickets/master/6324 -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 1/2] (#6324) Always fall back to svcadm enable except for the maintenance state
If state is running, using svcadm enable is harmless and prevents errors with execute(). Signed-off-by: Dominic Cleal --- Local-branch: tickets/master/6324 lib/puppet/provider/service/smf.rb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/puppet/provider/service/smf.rb b/lib/puppet/provider/service/smf.rb index 3efb2eb..042d339 100755 --- a/lib/puppet/provider/service/smf.rb +++ b/lib/puppet/provider/service/smf.rb @@ -54,10 +54,10 @@ Puppet::Type.type(:service).provide :smf, :parent => :base do def startcmd self.setupservice case self.status -when :stopped - [command(:adm), :enable, @resource[:name]] when :maintenance [command(:adm), :clear, @resource[:name]] +else + [command(:adm), :enable, @resource[:name]] end end -- 1.7.4 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 2/2] (#6324) Add spec for SMF service provider
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/6324
spec/unit/provider/service/smf_spec.rb | 133
1 files changed, 133 insertions(+), 0 deletions(-)
create mode 100755 spec/unit/provider/service/smf_spec.rb
diff --git a/spec/unit/provider/service/smf_spec.rb
b/spec/unit/provider/service/smf_spec.rb
new file mode 100755
index 000..4c52ed1
--- /dev/null
+++ b/spec/unit/provider/service/smf_spec.rb
@@ -0,0 +1,133 @@
+#!/usr/bin/env ruby
+#
+# Unit testing for the SMF service Provider
+#
+# author Dominic Cleal
+#
+require File.expand_path(File.dirname(__FILE__) + '/../../../spec_helper')
+
+provider_class = Puppet::Type.type(:service).provider(:smf)
+
+describe provider_class do
+
+ before(:each) do
+# Create a mock resource
+@resource = stub 'resource'
+@provider = provider_class.new(@resource)
+
+@resource.stubs(:[]).returns(nil)
+@resource.stubs(:[]).with(:name).returns "/system/myservice"
+@resource.stubs(:[]).with(:ensure).returns :enabled
+@resource.stubs(:[]).with(:enable).returns :true
+@resource.stubs(:name).returns "/system/myservice"
+@resource.stubs(:ref).returns "Service[/system/myservice]"
+@provider.stubs(:resource).returns @resource
+
+FileTest.stubs(:file?).with('/usr/sbin/svcadm').returns true
+FileTest.stubs(:executable?).with('/usr/sbin/svcadm').returns true
+FileTest.stubs(:file?).with('/usr/bin/svcs').returns true
+FileTest.stubs(:executable?).with('/usr/bin/svcs').returns true
+ end
+
+ it "should have a restart method" do
+@provider.should respond_to(:restart)
+ end
+
+ it "should have a restartcmd method" do
+@provider.should respond_to(:restartcmd)
+ end
+
+ it "should have a start method" do
+@provider.should respond_to(:start)
+ end
+
+ it "should have a stop method" do
+@provider.should respond_to(:stop)
+ end
+
+ it "should have an enabled? method" do
+@provider.should respond_to(:enabled?)
+ end
+
+ it "should have an enable method" do
+@provider.should respond_to(:enable)
+ end
+
+ it "should have a disable method" do
+@provider.should respond_to(:disable)
+ end
+
+ describe "when checking status" do
+it "should call the external command 'svcs /system/myservice' once" do
+ @provider.expects(:svcs).with('-H', '-o', 'state,nstate',
"/system/myservice").returns("online\t-")
+ @provider.status
+end
+it "should return stopped if svcs can't find the service" do
+ @provider.stubs(:svcs).raises(Puppet::ExecutionFailure.new("no svc
found"))
+ @provider.status.should == :stopped
+end
+it "should return running if online in svcs output" do
+ @provider.stubs(:svcs).returns("online\t-")
+ @provider.status.should == :running
+end
+it "should return stopped if disabled in svcs output" do
+ @provider.stubs(:svcs).returns("disabled\t-")
+ @provider.status.should == :stopped
+end
+it "should return maintenance if in maintenance in svcs output" do
+ @provider.stubs(:svcs).returns("maintenance\t-")
+ @provider.status.should == :maintenance
+end
+it "should return target state if transitioning in svcs output" do
+ @provider.stubs(:svcs).returns("online\tdisabled")
+ @provider.status.should == :stopped
+end
+it "should throw error if it's a legacy service in svcs output" do
+ @provider.stubs(:svcs).returns("legacy_run\t-")
+ lambda { @provider.status }.should raise_error(Puppet::Error, "Cannot
manage legacy services through SMF")
+end
+ end
+
+ describe "when starting" do
+it "should enable the service if it is not enabled" do
+ @provider.expects(:status).returns :stopped
+ @provider.expects(:texecute)
+ @provider.start
+end
+
+it "should always execute external command 'svcadm enable
/system/myservice'" do
+ @provider.stubs(:status).returns :running
+ @provider.expects(:texecute).with(:start, ["/usr/sbin/svcadm", :enable,
"/system/myservice"], true)
+ @provider.start
+end
+
+it "should execute external command 'svcadm clear /system/myservice' if in
maintenance" do
+ @provider.stubs(:status).returns :maintenance
+ @provider.expects(:texecute).with(:start, ["/usr/sbin/svcadm", :clear,
"/system/myservice"], true)
+ @provider.start
+end
+
+it "should import the manifest if service is not found" do
+ @resource.stubs(:[]).with(:manifest).returns("/tmp/
Re: [Puppet-dev] [PATCH/puppet 1/1] (#6324) Always fall back to svcadm enable except for the maintenance state
On 15/02/11 21:21, Luke Kanies wrote: > Good catch, and definitely a good idea. > > I don't suppose you feel like creating a set of SMF tests for this? :) I've given it a go, but getting the rspec to work was a steep learning curve! I'll resend the patches. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 1/1] (#6324) Always fall back to svcadm enable except for the maintenance state
If state is running, using svcadm enable is harmless and prevents errors with execute(). Signed-off-by: Dominic Cleal --- Local-branch: tickets/master/6324 lib/puppet/provider/service/smf.rb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/puppet/provider/service/smf.rb b/lib/puppet/provider/service/smf.rb index 3efb2eb..042d339 100755 --- a/lib/puppet/provider/service/smf.rb +++ b/lib/puppet/provider/service/smf.rb @@ -54,10 +54,10 @@ Puppet::Type.type(:service).provide :smf, :parent => :base do def startcmd self.setupservice case self.status -when :stopped - [command(:adm), :enable, @resource[:name]] when :maintenance [command(:adm), :clear, @resource[:name]] +else + [command(:adm), :enable, @resource[:name]] end end -- 1.7.4 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/facter 1/1] Fixed #5950 - Solaris ipaddress incorrect after bonding failure
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/5950
lib/facter/ipaddress.rb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/facter/ipaddress.rb b/lib/facter/ipaddress.rb
index a08f26b..c053251 100644
--- a/lib/facter/ipaddress.rb
+++ b/lib/facter/ipaddress.rb
@@ -47,7 +47,7 @@ Facter.add(:ipaddress) do
output.split(/^\S/).each { |str|
if str =~ /inet ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/
tmp = $1
-unless tmp =~ /^127\./
+unless tmp =~ /^127\./ or tmp == "0.0.0.0"
ip = tmp
break
end
--
1.7.3.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] New Type for managing /etc/project on Solaris
On 04/12/10 12:12, Stefan Schulte wrote: > I wrote a new type to manage projects in Solaris. Projects are used to > do resource management. Here's a sample usage > > [snip] > > I would love to have some feedback and if you think that project > is a resourcetype that could be integrated in puppet core I will > open a corresponding feature request. I like the idea, could have saved me some time last week! Earlier this week I was thinking that it'd be useful to have a project_attribute type for modifying built-in projects (i.e. default). The ensure value "present" would map well to "projmod -s" and "absent" to "projmod -r". It'd probably conflict with your project provider though for custom projects. It only really makes sense to define a custom project once and specify all attributes there, at the expense of not being able to specify attributes of a built-in project as individual resources. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/facter 1/2] (#1423) Refactoring OpenBSD vmstat call to utility method
Moved vmstat exec to Facter::Memory::Util so it can used to retrieve free
memory in the same way on Solaris.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/1423
lib/facter/memory.rb |8 +---
lib/facter/util/memory.rb | 10 ++
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/lib/facter/memory.rb b/lib/facter/memory.rb
index 06640e6..8eab377 100644
--- a/lib/facter/memory.rb
+++ b/lib/facter/memory.rb
@@ -69,13 +69,7 @@ if Facter.value(:kernel) == "OpenBSD"
end
end
-Facter.add("MemoryFree") do
-confine :kernel => :openbsd
-memfree = Facter::Util::Resolution.exec("vmstat | tail -n 1 | awk '{
print $5 }'")
-setcode do
-Facter::Memory.scale_number(memfree.to_f,"kB")
-end
-end
+Facter::Memory.vmstat_find_free_memory()
Facter.add("MemoryTotal") do
confine :kernel => :openbsd
diff --git a/lib/facter/util/memory.rb b/lib/facter/util/memory.rb
index 2004491..5687ff2 100644
--- a/lib/facter/util/memory.rb
+++ b/lib/facter/util/memory.rb
@@ -50,5 +50,15 @@ module Facter::Memory
return "%.2f %s" % [size, s]
end
+
+def self.vmstat_find_free_memory()
+row = Facter::Util::Resolution.exec("vmstat").split("\n")[-1]
+Facter.add("MemoryFree") do
+memfree = row.split[4]
+setcode do
+Facter::Memory.scale_number(memfree.to_f, "kB")
+end
+end
+end
end
--
1.7.3.2
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/facter 2/2] (#1423) Memory facts for Solaris
Add total memory from prtconf output, free from vmstat plus swap free and
total from swap -l listing.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/1423
lib/facter/memory.rb | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/lib/facter/memory.rb b/lib/facter/memory.rb
index 8eab377..f744c3f 100644
--- a/lib/facter/memory.rb
+++ b/lib/facter/memory.rb
@@ -79,3 +79,46 @@ if Facter.value(:kernel) == "OpenBSD"
end
end
end
+
+if Facter.value(:kernel) == "SunOS"
+swap = Facter::Util::Resolution.exec('/usr/sbin/swap -l')
+swapfree, swaptotal = 0, 0
+swap.each do |dev|
+if dev =~ /^\/\S+\s.*\s+(\d+)\s+(\d+)$/
+swaptotal += $1.to_i / 2
+swapfree += $2.to_i / 2
+end
+end
+
+Facter.add("SwapSize") do
+confine :kernel => :sunos
+setcode do
+Facter::Memory.scale_number(swaptotal.to_f,"kB")
+end
+end
+
+Facter.add("SwapFree") do
+confine :kernel => :sunos
+setcode do
+Facter::Memory.scale_number(swapfree.to_f,"kB")
+end
+end
+
+# Total memory size available from prtconf
+pconf = Facter::Util::Resolution.exec('/usr/sbin/prtconf')
+phymem = ""
+pconf.each do |line|
+if line =~ /^Memory size:\s+(\d+) Megabytes/
+phymem = $1
+end
+end
+
+Facter.add("MemorySize") do
+confine :kernel => :sunos
+setcode do
+Facter::Memory.scale_number(phymem.to_f,"MB")
+end
+end
+
+Facter::Memory.vmstat_find_free_memory()
+end
--
1.7.3.2
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/facter 1/1] (#2066) Make units optional
On 01/12/10 13:10, Paul Nasrat wrote: > On 1 December 2010 10:49, Dominic Cleal wrote: >> On 01/12/10 10:32, Dominic Cleal wrote: >>> Memory and swap values are now given in standard units via additional facts >>> (e.g. memorysize_mb) as well as the most appropriate unit as before. >> >> Please note that this conflicts with the patch I submitted yesterday for >> #1423 (Solaris memory facts), but I thought it'd be good to get it out >> there for review anyway. I'm happy to update and resubmit this if/when >> the other is merged or vice versa. > > I'd rather not make this change right now as I think we want a > consistent approach with in Facter to handle this. Lets use this patch > as a way to spark discussion but apply the 1423 patch right now. Sure, hopefully it serves to show the result I'm looking for as a user. Are you thinking to include this in the 2.0 redesign? -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/facter 1/1] (#1423) Memory facts for Solaris
On 02/12/10 23:27, Paul Berry wrote: > On Tue, Nov 30, 2010 at 4:27 AM, Dominic Cleal <mailto:dcl...@redhat.com>> wrote: > > Add total memory from prtconf output, free from vmstat plus swap > free and > total from swap -l listing. > > Signed-off-by: Dominic Cleal <mailto:dcl...@redhat.com>> > > It looks like there are two independent changes here. In addition to > adding facts for SunOS, this change refactors the OpenBSD MemoryFree > fact, moving it to util/memory.rb and rewriting it to use a regular > expression. Was the OpenBSD change intentional? Because if so it > should probably be in a separate commit, and also it probably could be > better written using split() rather than a regular expression to pick > out the fifth column. Thanks for the feedback Paul. The change was intentional as the Solaris MemoryFree code would have been identical. I'll resubmit this as two separate commits and use split(). Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/facter 1/1] (#2066) Make units optional
On 01/12/10 10:32, Dominic Cleal wrote: > Memory and swap values are now given in standard units via additional facts > (e.g. memorysize_mb) as well as the most appropriate unit as before. Please note that this conflicts with the patch I submitted yesterday for #1423 (Solaris memory facts), but I thought it'd be good to get it out there for review anyway. I'm happy to update and resubmit this if/when the other is merged or vice versa. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/facter 1/1] (#2066) Make units optional
Memory and swap values are now given in standard units via additional facts
(e.g. memorysize_mb) as well as the most appropriate unit as before.
Standard units provided are B and MB.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/2066
lib/facter/memory.rb | 70 ++--
lib/facter/util/memory.rb | 57
2 files changed, 79 insertions(+), 48 deletions(-)
diff --git a/lib/facter/memory.rb b/lib/facter/memory.rb
index 06640e6..992ed40 100644
--- a/lib/facter/memory.rb
+++ b/lib/facter/memory.rb
@@ -7,16 +7,14 @@
#
require 'facter/util/memory'
-{ :MemorySize => "MemTotal",
-:MemoryFree => "MemFree",
-:SwapSize => "SwapTotal",
-:SwapFree => "SwapFree"
-}.each do |fact, name|
-Facter.add(fact) do
-confine :kernel => :linux
-setcode do
-Facter::Memory.meminfo_number(name)
-end
+if Facter.value(:kernel) == "Linux"
+{ :MemorySize => "MemTotal",
+:MemoryFree => "MemFree",
+:SwapSize => "SwapTotal",
+:SwapFree => "SwapFree"
+}.each do |fact, name|
+meminfo = Facter::Memory.meminfo_number(name)
+Facter::Memory::add_memfacts(fact, meminfo, :linux)
end
end
@@ -30,19 +28,11 @@ if Facter.value(:kernel) == "AIX" and Facter.value(:id) ==
"root"
end
end
-Facter.add("SwapSize") do
-confine :kernel => :aix
-setcode do
-Facter::Memory.scale_number(swaptotal.to_f,"MB")
-end
-end
+meminfo = Facter::Memory.scale_number(swaptotal.to_f,"MB")
+Facter::Memory::add_memfacts("SwapSize", meminfo, :aix)
-Facter.add("SwapFree") do
-confine :kernel => :aix
-setcode do
-Facter::Memory.scale_number(swapfree.to_f,"MB")
-end
-end
+meminfo = Facter::Memory.scale_number(swapfree.to_f,"MB")
+Facter::Memory::add_memfacts("SwapFree", meminfo, :aix)
end
if Facter.value(:kernel) == "OpenBSD"
@@ -55,33 +45,17 @@ if Facter.value(:kernel) == "OpenBSD"
end
end
-Facter.add("SwapSize") do
-confine :kernel => :openbsd
-setcode do
-Facter::Memory.scale_number(swaptotal.to_f,"kB")
-end
-end
+meminfo = Facter::Memory.scale_number(swaptotal.to_f,"kB")
+Facter::Memory::add_memfacts("SwapSize", meminfo, :openbsd)
-Facter.add("SwapFree") do
-confine :kernel => :openbsd
-setcode do
-Facter::Memory.scale_number(swapfree.to_f,"kB")
-end
-end
+meminfo = Facter::Memory.scale_number(swapfree.to_f,"kB")
+Facter::Memory::add_memfacts("SwapFree", meminfo, :openbsd)
-Facter.add("MemoryFree") do
-confine :kernel => :openbsd
-memfree = Facter::Util::Resolution.exec("vmstat | tail -n 1 | awk '{
print $5 }'")
-setcode do
-Facter::Memory.scale_number(memfree.to_f,"kB")
-end
-end
+memfree = Facter::Util::Resolution.exec("vmstat | tail -n 1 | awk '{ print
$5 }'")
+meminfo = Facter::Memory.scale_number(memfree.to_f,"kB")
+Facter::Memory::add_memfacts("MemoryFree", meminfo, :openbsd)
-Facter.add("MemoryTotal") do
-confine :kernel => :openbsd
-memtotal = Facter::Util::Resolution.exec("sysctl hw.physmem | cut
-d'=' -f2")
-setcode do
-Facter::Memory.scale_number(memtotal.to_f,"")
-end
-end
+memtotal = Facter::Util::Resolution.exec("sysctl hw.physmem | cut -d'='
-f2")
+meminfo = Facter::Memory.scale_number(memfree.to_f,"")
+Facter::Memory::add_memfacts("MemoryTotal", meminfo, :openbsd)
end
diff --git a/lib/facter/util/memory.rb b/lib/facter/util/memory.rb
index 2004491..672c452 100644
--- a/lib/facter/util/memory.rb
+++ b/lib/facter/util/memory.rb
@@ -16,6 +16,28 @@
module Facter::Memory
require 'thread'
+# Stores all units from meminfo as fact_SUFFIX
+def self.add_memfacts(fact, meminfo, kernel = nil)
+best = meminfo[:best]
+Facter.add(fact) do
+confine :kernel => kernel if kernel
+setcode do
+best
+end
+end
+
+# Load in values converted to other units
+meminfo.each do |memunit,memsize|
+next if memunit == :best
+Facter.add("%s_%s" % [fact, memunit]) do
+confine :kernel => kernel if kernel
+setcode do
+
[Puppet-dev] [PATCH/facter 1/1] (#1423) Memory facts for Solaris
Add total memory from prtconf output, free from vmstat plus swap free and
total from swap -l listing.
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/1423
lib/facter/memory.rb | 51 ++--
lib/facter/util/memory.rb | 12 ++
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/lib/facter/memory.rb b/lib/facter/memory.rb
index 06640e6..f744c3f 100644
--- a/lib/facter/memory.rb
+++ b/lib/facter/memory.rb
@@ -69,13 +69,7 @@ if Facter.value(:kernel) == "OpenBSD"
end
end
-Facter.add("MemoryFree") do
-confine :kernel => :openbsd
-memfree = Facter::Util::Resolution.exec("vmstat | tail -n 1 | awk '{
print $5 }'")
-setcode do
-Facter::Memory.scale_number(memfree.to_f,"kB")
-end
-end
+Facter::Memory.vmstat_find_free_memory()
Facter.add("MemoryTotal") do
confine :kernel => :openbsd
@@ -85,3 +79,46 @@ if Facter.value(:kernel) == "OpenBSD"
end
end
end
+
+if Facter.value(:kernel) == "SunOS"
+swap = Facter::Util::Resolution.exec('/usr/sbin/swap -l')
+swapfree, swaptotal = 0, 0
+swap.each do |dev|
+if dev =~ /^\/\S+\s.*\s+(\d+)\s+(\d+)$/
+swaptotal += $1.to_i / 2
+swapfree += $2.to_i / 2
+end
+end
+
+Facter.add("SwapSize") do
+confine :kernel => :sunos
+setcode do
+Facter::Memory.scale_number(swaptotal.to_f,"kB")
+end
+end
+
+Facter.add("SwapFree") do
+confine :kernel => :sunos
+setcode do
+Facter::Memory.scale_number(swapfree.to_f,"kB")
+end
+end
+
+# Total memory size available from prtconf
+pconf = Facter::Util::Resolution.exec('/usr/sbin/prtconf')
+phymem = ""
+pconf.each do |line|
+if line =~ /^Memory size:\s+(\d+) Megabytes/
+phymem = $1
+end
+end
+
+Facter.add("MemorySize") do
+confine :kernel => :sunos
+setcode do
+Facter::Memory.scale_number(phymem.to_f,"MB")
+end
+end
+
+Facter::Memory.vmstat_find_free_memory()
+end
diff --git a/lib/facter/util/memory.rb b/lib/facter/util/memory.rb
index 2004491..43abec6 100644
--- a/lib/facter/util/memory.rb
+++ b/lib/facter/util/memory.rb
@@ -50,5 +50,17 @@ module Facter::Memory
return "%.2f %s" % [size, s]
end
+
+def self.vmstat_find_free_memory()
+row = Facter::Util::Resolution.exec('vmstat').split("\n")[-1]
+if row =~ /^\s*\d+\s*\d+\s*\d+\s*\d+\s*(\d+)/
+Facter.add("MemoryFree") do
+memfree = $1
+setcode do
+Facter::Memory.scale_number(memfree.to_f, "kB")
+end
+end
+end
+end
end
--
1.7.3.2
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
Re: [Puppet-dev] [PATCH/puppet 1/1] Fixed #4258 - Added pkgutil package provider for Solaris
On 29/11/10 12:59, Dominic Cleal wrote: > Fixed #4258 - Added pkgutil package provider for Solaris This is an attempt to tie up the pkgutil patches from James, Maciej Bliziński, Rudy Gevaert and me. There has also been a thread running on puppet-users[1] which includes the pkgutil author (Peter Bonivart). I don't think the exit code change for non-existent packages is a requirement and from my limited testing of installing packages, I'm happy with the provider. [1] http://groups.google.com/group/puppet-users/browse_thread/thread/6a0f2de37b515e34/5a985dec36b209d9 -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/puppet 1/1] Fixed #4258 - Added pkgutil package provider for Solaris
Signed-off-by: Dominic Cleal
---
Local-branch: tickets/master/4258
lib/puppet/provider/package/pkgutil.rb | 127
1 files changed, 127 insertions(+), 0 deletions(-)
create mode 100755 lib/puppet/provider/package/pkgutil.rb
diff --git a/lib/puppet/provider/package/pkgutil.rb
b/lib/puppet/provider/package/pkgutil.rb
new file mode 100755
index 000..dacd70a
--- /dev/null
+++ b/lib/puppet/provider/package/pkgutil.rb
@@ -0,0 +1,127 @@
+# Packaging using Peter Bonivart's pkgutil program.
+Puppet::Type.type(:package).provide :pkgutil, :parent => :sun, :source => :sun
do
+ desc "Package management using Peter Bonivart's ``pkgutil`` command on
Solaris."
+ pkguti = "pkgutil"
+ if FileTest.executable?("/opt/csw/bin/pkgutil")
+pkguti = "/opt/csw/bin/pkgutil"
+ end
+
+ confine :operatingsystem => :solaris
+
+ commands :pkguti => pkguti
+
+ def self.extended(mod)
+unless command(:pkguti) != "pkgutil"
+ raise Puppet::Error,
+"The pkgutil command is missing; pkgutil packaging unavailable"
+end
+
+unless FileTest.exists?("/var/opt/csw/pkgutil/admin")
+ Puppet.notice "It is highly recommended you create
'/var/opt/csw/pkgutil/admin'."
+ Puppet.notice "See /var/opt/csw/pkgutil"
+end
+ end
+
+ def self.instances(hash = {})
+pkglist(hash).collect do |bhash|
+ bhash.delete(:avail)
+ new(bhash)
+end
+ end
+
+ # Turn our pkgutil -c listing into a bunch of hashes.
+ # Supports :justme => packagename, which uses the optimised --single arg
+ def self.pkglist(hash)
+command = ["-c"]
+
+if hash[:justme]
+ # The --single option speeds up the execution, because it queries
+ # the package managament system for one package only.
+ command << ["--single"]
+ command << hash[:justme]
+end
+
+output = pkguti command
+
+list = output.split("\n").collect do |line|
+ next if line =~ /^#/
+ next if line =~ /installed\s+catalog/ # header of package list
+ next if line =~ /^Checking integrity / # use_gpg
+ next if line =~ /^gpg: / # gpg verification
+ next if line =~ /^=+> /# catalog fetch
+ next if line =~ /\d+:\d+:\d+ URL:/ # wget without -q
+
+ parsed = pkgsplit(line)
+
+ # When finding one package, ensure we picked up the package line
+ # itself, not any pkgutil noise.
+ next if hash[:justme] and parsed[:name] != hash[:justme]
+
+ parsed
+end.reject { |h| h.nil? }
+
+if hash[:justme]
+ return list[-1]
+else
+ list.reject! { |h|
+h[:ensure] == :absent
+ }
+ return list
+end
+
+ end
+
+ # Split the different lines into hashes.
+ def self.pkgsplit(line)
+if line =~ /\s*(\S+)\s+(\S+)\s+(.*)/
+ hash = {}
+ hash[:name] = $1
+ hash[:ensure] = if $2 == "notinst"
+:absent
+ else
+$2
+ end
+ hash[:avail] = $3
+
+ if hash[:avail] == "SAME"
+hash[:avail] = hash[:ensure]
+ end
+
+ # Use the name method, so it works with subclasses.
+ hash[:provider] = self.name
+
+ return hash
+else
+ Puppet.warning "Cannot match %s" % line
+ return nil
+end
+ end
+
+ def install
+pkguti "-y", "-i", @resource[:name]
+ end
+
+ # Retrieve the version from the current package file.
+ def latest
+hash = self.class.pkglist(:justme => @resource[:name])
+hash[:avail]
+ end
+
+ def query
+if hash = self.class.pkglist(:justme => @resource[:name])
+ hash
+else
+ {:ensure => :absent}
+end
+ end
+
+ # Remove the old package, and install the new one
+ def update
+pkguti "-y", "-i", @resource[:name]
+ end
+
+ def uninstall
+pkguti "-y", "-r", @resource[:name]
+ end
+end
+
--
1.7.3.2
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
[Puppet-dev] [PATCH/facter 1/1] (#5325) Manufacturer and product name on SPARC
Use prtdiag output on Solaris/SPARC to determine manufacturer and productname as
smbios is unavailable.
Signed-off-by: Dominic Cleal
---
Local-branch: ticket/master/5325
lib/facter/manufacturer.rb |2 ++
lib/facter/util/manufacturer.rb | 20
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/lib/facter/manufacturer.rb b/lib/facter/manufacturer.rb
index 9d66465..cbbb88b 100644
--- a/lib/facter/manufacturer.rb
+++ b/lib/facter/manufacturer.rb
@@ -13,6 +13,8 @@ if Facter.value(:kernel) == "OpenBSD"
}
Facter::Manufacturer.sysctl_find_system_info(mfg_keys)
+elsif Facter.value(:kernel) == "SunOS" and Facter.value(:hardwareisa) ==
"sparc"
+Facter::Manufacturer.prtdiag_sparc_find_system_info()
else
query = {
'[Ss]ystem [Ii]nformation' => [
diff --git a/lib/facter/util/manufacturer.rb b/lib/facter/util/manufacturer.rb
index 112380b..5ac0585 100644
--- a/lib/facter/util/manufacturer.rb
+++ b/lib/facter/util/manufacturer.rb
@@ -60,4 +60,24 @@ module Facter::Manufacturer
end
end
end
+
+def self.prtdiag_sparc_find_system_info()
+# Parses prtdiag for a SPARC architecture string, won't work with
Solaris x86
+output = Facter::Util::Resolution.exec('/usr/sbin/prtdiag')
+
+# System Configuration: Sun Microsystems sun4u Sun SPARC Enterprise
M3000 Server
+sysconfig = output.split("\n")[0]
+if sysconfig =~ /^System Configuration:\s+(.+?)\s+(sun\d+\S+)\s+(.+)/
then
+Facter.add('manufacturer') do
+setcode do
+$1
+end
+end
+Facter.add('productname') do
+setcode do
+$3
+end
+end
+end
+end
end
--
1.7.3.2
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
