from:"David Schmitt"

Re: [Puppet-dev] Availability of Facter 4 nightly gems

2021-05-20 Thread David Schmitt

Are these also fed into the nightly agent builds, or do I need additional
steps to get nightly facter on top of a nightly agent build?

On Thu, 20 May 2021 at 13:40, Gabriel Nagy  wrote:

> Hello,
>
> We are happy to announce that Facter 4 nightly gems are now available to
> use under http://nightlies.puppet.com/downloads/gems/facter-nightly/
> We highly encourage folks who are interested in the latest Facter 4
> features and fixes to try out the builds. Please note that nightly builds
> come with a degree of instability, but it's the best way to test out
> features that have not yet been officially released.
>
> As always, we welcome your feedback either on the #puppet Slack channel (
> slack.puppet.com), and if you find any issues please open a ticket on our
> JIRA under the FACT project: http://tickets.puppetlabs.com/browse/FACT
>
> Gabriel Nagy
> Software Engineer - Puppet
>
> --
> 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/CAALo1wFET5PLKm7u0q%2BNfjzKEX%3DBN%2BHjrLwMWAivsm7-ceUQLA%40mail.gmail.com
> 
> .
>

-- 
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/CALF7fHa3WdG9%3DDfFSD7_yGQb7NDK%2BDCio5GywxdOXN9RDEouEA%40mail.gmail.com.

Re: [Puppet-dev] How to update context.xml of tomcat

2019-04-01 Thread David Schmitt

Hi Kiran,

have a look at the https://forge.puppet.com/puppetlabs/tomcat module. The
reference contains details on the available functionality for contexts.

Regards, David

On Fri, Mar 29, 2019 at 5:39 PM Kiran Somisetty 
wrote:

> Hi
>   I want to update context.xml file of tomcat.
>   Can you pls help me how can I do it using pupped?
>
> Thanks
> Kiran.
>
> --
> 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/3fe3bf5f-7455-486f-b65b-6c71fa52a7a0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHbMwP_QGhmkfekp-PnM1-enOYw1itNxZZ64br2%3DUn-Yrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] [ANN] Resource API v1.6.0 Release

2018-09-25 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.6.0 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. Using a little bit of ruby, you
can finally get rid of that brittle exec, or manage that one API that
eluded you until now.

It is provided as a Ruby gem to be referenced within modules. Support for
it has been included as an experimental feature in the Puppet Development
Kit (see pdk new provider --help). Use the resource_api module
<https://forge.puppet.com/puppetlabs/resource_api> or the puppet 6 packages
<https://puppet.com/blog/introducing-puppet-6> to deploy it in your
infrastructure.

The new release of the Resource API provides the following enhancements:

- Allow SimpleProvider to handle composite namevars.
- Implement allowances for device-specific providers.

The new release also contains the following notable changes:

- Updates to the README
- Add testing for supported puppet version branches

See the CHANGELOG
<https://github.com/puppetlabs/puppet-resource_api/blob/master/CHANGELOG.md>
for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README
<https://github.com/puppetlabs/puppet-resource_api/blob/master/README.md>
gets you going quickly. To see some example code see this simple Philips
Hue type <https://github.com/da-ar/hue_rsapi> or the Palo Alto firewall
module <https://github.com/puppetlabs/puppetlabs-panos>.

Please let us know of your experiences with the Resource API, either here,
on Slack <https://slack.puppet.com/> (#forge-modules), or on the github repo
<https://github.com/puppetlabs/puppet-resource_api>.

Thanks, David Schmitt
--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHa_j181LUf155HUyDzm%2BJ2cyb5LvZwipkGtdc25WZUAkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] rake module:push, puppet-blacksmith, and puppet 6

2018-09-19 Thread David Schmitt

Hi folks,

until tomorrow's PDK and puppetlabs_spec_helper release automated module
release jobs will need to have their puppet pinned to `~> 5.0`, to keep
using the deprecated `puppet module build` command, which was removed in
yesterday's puppet 6.0.0 release.

You can follow along PDK-1100
 for the actual change
required.


Apologies for the additional hiccup along the way,
David
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHZ26Pm5VeAnS1V6JOUOtxubDc8Nqq%3DA2SBHJ2wZ%3Diz3Uw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] [ANN] Resource API v1.5.0 Release

2018-09-13 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.5.0 of the Resource API has just
been released.

It is provided as a Ruby gem that can be installed on all puppet versions
since 4.7, and will be part of puppet6. Support for it has been included as
an experimental feature in the Puppet Development Kit (see pdk new provider
--help). Use the resource_api module
<https://forge.puppet.com/puppetlabs/resource_api> or the puppet 6 nightly
packages
<https://groups.google.com/d/msg/puppet-users/N3LJGhsrqkU/TUEsq7VfDQAJ> to
deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

- Allow providers to specify a title when there are multiple namevars,
to make title patterns more usable. PDK-1150
<https://tickets.puppetlabs.com/browse/PDK-1150> #115
<https://github.com/puppetlabs/puppet-resource_api/pull/115> (da-ar
<https://github.com/da-ar>)
- Sensitive values are now usable like any other puppet4 datatype.
PDK-1092 <https://tickets.puppetlabs.com/browse/PDK-1091> #117
<https://github.com/puppetlabs/puppet-resource_api/pull/117> (DavidS
<https://github.com/DavidS>)
- The puppetlabs-resource_api module now "supports" puppet 6. With the
integration of Resource API in puppet 6, the module technically is not
needed anymore. For backwards compatibility, and to provide a uniform
experience across all puppet versions, it is still available, and will work
on puppet6 (doing nothing).

The new release also contains the following notable bugfixes:

- providers that implement simple_get_filter, are now handled correctly.
MODULES-7679 #113
<https://github.com/puppetlabs/puppet-resource_api/pull/113> (da-ar
<https://github.com/da-ar>)
- default values are not shared across all resource instances anymore.
#118 <https://github.com/puppetlabs/puppet-resource_api/pull/118> (DavidS
<https://github.com/DavidS>)

See the CHANGELOG
<https://github.com/puppetlabs/puppet-resource_api/blob/master/CHANGELOG.md>
for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README
<https://github.com/puppetlabs/puppet-resource_api/blob/master/README.md>
gets you going quickly. To see some example code see this simple Philips
Hue type <https://github.com/da-ar/hue_rsapi> or this experimental apt_key
provider
<https://github.com/DavidS/puppetlabs-apt/blob/resource-api-experiments/lib/puppet/provider/apt_key2/apt_key2.rb>
.

Thanks, David Schmitt for the Resource API maintainers.
--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHaa50emQ%3DE2r2O6QgkUr6XhtFmOvOcdUs%3DCw-see9t_UQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] [ANN] Resource API v1.4.2 Release

2018-08-09 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.4.2 of the Resource API is being
released today.

It is provided as a Ruby gem to be referenced within modules. Support for
it has been included as an experimental feature in the Puppet Development
Kit (see pdk new provider --help). Use the resource_api module
or the puppet 6 nightly
packages
to
deploy it in your infrastructure.

The new release of the Resource API following notable bugfix:

- Allow an attribute with default boolean value to be set correctly #110
(da-ar
)

See the CHANGELOG

for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README

gets you going quickly. To see some example code see this simple Philips
Hue type or this experimental apt_key
provider

Please let us know of your experiences with the Resource API, either here,
on Slack (#forge-modules), or on the github repo
.

Thanks, the other David
--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHYVSpjMz3vwM7LXro-RFB_LgjUHguOUU3pNDBvaW6rQfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] [ANN] Resource API v1.4.1 Release

2018-07-20 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.4.1 of the Resource API is being
released today.

It is provided as a Ruby gem to be referenced within modules. Support for
it has been included as an experimental feature in the Puppet Development
Kit (see pdk new provider --help). Use the resource_api module
or the puppet 6 nightly
packages
to
deploy it in your infrastructure.

The new release of the Resource API provides the following notable bugfixes:

- Fix "undefined method `rs_value'" error with metaparams like require
and subscribe
- Improve log_exception output from PuppetContext
- Minor code changes to allow providers be loaded without puppet

See the CHANGELOG

for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README

gets you going quickly. To see some example code see this simple Philips
Hue type or this experimental apt_key
provider

Please let us know of your experiences with the Resource API, either here,
on Slack (#forge-modules), or on the github repo
.

Thanks, the Davids
--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHZSZ0RfcXth9SU_c%3DY7wLgdBiqHpYSi858T91G%3DG95vRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] [ANN] Resource API v1.4.0 Release

2018-06-20 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.4.0 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. It is provided as a Ruby gem to
be referenced within modules. Support for it has been included as an
experimental feature in version 1.4 of the Puppet Development Kit (pdk new
provider). Use the resource_api module
<https://forge.puppet.com/puppetlabs/resource_api> or the puppet 6 nightly
packages
<https://groups.google.com/d/msg/puppet-users/N3LJGhsrqkU/TUEsq7VfDQAJ> to
deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

- Purging with resources { 'your_type': purge => true } works now for
Resource API types. This allows users of your type to clean up everything
that is not managed by the current catalog. (PDK-1007)
- Enhanced validation for developers: the Resource API now checks return
values from get() against the type's definition. This aids in finding
bugs in the provider itself earlier and can be turned on and off through
puppet's --strict setting. (PDK-917)
- To make device-based code better re-usable, the SimpleDevice class now
also takes configuration as a Hash. (#96)

The new release also contains the following notable bugfixes:

- Exception handling during batch operations has been fixed to show all
stack traces for better debugability (#101)
- Empty (nil) attribute values are not printed from puppet resource
(#100)
- Improved error messages on data type errors in the type definition
(PDK-996)

See the CHANGELOG
<https://github.com/puppetlabs/puppet-resource_api/blob/master/CHANGELOG.md>
for a full list of changes

We encourage all module developers to review the Resource API and use it
when creating types and providers. For reference, there is an example of
its usage in a branch
<https://github.com/DavidS/puppetlabs-apt/blob/resource-api-experiments/lib/puppet/provider/apt_key2/apt_key2.rb>
of the apt module.

Thanks, David Schmitt & David Armstrong
--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHZiLSwVPd0AJ2PeDYtpYf4OSkdPgG03Q7Zcg5BCQ9GA3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] [ANN] Resource API v1.2 Release

2018-05-08 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.2 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. It is provided as a Ruby gem to
be referenced within modules. Support for it has been included as an
experimental feature in version 1.4 of the Puppet Development Kit (pdk new
provider). Use the resource_api module
or the puppet 6 nightly
packages
to
deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

- Provide access to the type definition from the provider. This can be
useful in advanced scenarios, e.g. for autogenerating API-passthroughs
based on the resource type. See puppetlabs/puppet-resource_api#72
and
puppetlabs/puppet-specifications:
resource-api/README.md#type-definition

for technical details
- SimpleProvider now throws a usable error when the type does not have
an ensure attribute. Previously this would have caused confusing errors,
which were hard to figure out.
- The Resource API is now shipped as an integral part of the puppet 6
nightly packages
.

The new release also contains the following notable bugfixes:

- ensure values are now passed to puppet as symbols. While the Enum data
type is a string, puppet expects symbols for ensure to activate its special
handling for ensure. This version of the Resource API restores the
symbolization behaviour on the puppet side, without disturbing providers
expecting a string.
- The Resource API no longer validates attribute values on resources
that should be absent. This matches existing puppet behaviour, and is
necessary to be able to delete resources without having to specify a
(otherwise) valid configuration.

See the CHANGELOG

for a full list of changes

We encourage all module developers to review the Resource API and use it
when creating types and providers. For reference, there is an example of
its usage in a branch

of the apt module.

Please let us know of your experiences with the Resource API, either here,
on Slack (#forge-modules), or on the github repo
.

Thanks, David
--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHa7yy9Ptf6ewD7DbUvTH3D75r3fyUa68Mh8vYk%3D_EgFkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] [ANN] Resource API v1.1 Release

2018-04-13 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.1 of the Resource API has been
released yesterday.

The new release of the Resource API provides the following enhancements:

- Arrays are now fully supported as data types (v1.1.0)
- Read only and init only attributes have that status now fully enforced
(v1.0.3)

The new release also contains the following notable bugfixes:

- PDK-911 : handling of
ensure values changed to use strings: Previous to v1.0.3, in some cases
ensure values of 'absent' and 'present' would be transformed to ruby
symbols before passing it on to the provider. This behavior was
inconsistent with both puppet and other Enums in the Resource API, that
would always use strings. Providers now need to return and accept the
strings 'absent' and 'present' instead of the :absent and :present
symbols.
- PDK-919 : Boolean
attributes now work in all cases: In some cases
puppet can ignore true
boolean values. The Resource API now works around the issue in a
transparent way that requires no change to providers.

See the CHANGELOG

for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. For reference, there is an example of
its usage in a branch

of the apt module.

Please let us know of your experiences with the Resource API, either here,
on Slack (#forge-modules), or on the github repo
.

Thanks,

David
--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHbTL5U2iU-wcVnULerPvw08%2B%3D%2BxgoKvytNrDRLhpOcRrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Announcement: Resource API v1.0 release

2018-03-23 Thread David Schmitt

Hi all,

We're pleased to announce that version 1.0 of the Resource API
is being launched today.

The Resource API provides the following functionality:

Simple type and provider definition.
-

Use Puppet 4+ data types.
-

Canonicalize, simple_get_filter, and remote_resource features.
-

Logging facilities.
-

New providers are compatible with all puppet commands:
-

puppet apply
-

puppet resource
-

puppet agent
-

puppet device (if applicable)

To ease adoption of the Resource API there is a module
on the Forge to install
it in your Puppet Server or Puppet Agent. The Resource API gem must be
installed in order to use modules that have types and providers created
using the Resource API. In the future we are planning to bundle the
Resource API with the Puppet platform.

We encourage all module developers to review the Resource API and use it
when creating modules that have types and providers. For reference, there
is an example of its usage in a branch

of the apt module.

Please let us know of your experiences with the Resource API.

Thanks.

--
Cheers, David

https://twitter.com/dev_el_ops

--
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/CALF7fHZFvvKGWrCgNU-wckrGCei9x%3DLZdCc7Tu18U%2Bu6fene0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: [ANN] Puppet Development Kit (pdk) preview (0.6.0)

2017-08-11 Thread David Schmitt

On 11 August 2017 at 19:06, Corey Osman  wrote:

> I haven't messed with PDK yet.  What problems is this new tool solving
> though?  How is it different from puppet-retrospec?
> https://github.com/nwops/puppet-retrospec
>

The main problems the PDK attacks today are

   - *Complexity of setting up a development environment. *Especially ruby
   on windows is ... uncooperative. With the native packages you're up and
   running within seconds after you have downloaded them. Additionally, the
   current packages are built using the puppet 4 ruby (and future versions
   will *also* contain the puppet 5 ruby, supporting new releases as we go),
   which means you'll get high assurance, that your (native) code will run on
   the agent.
   - *The first 60 minutes of development.* With at least five different
   major module skeletons, and generators (puppet module generate,
   garethr/puppet-module-skeleton, voxpupuli's modulesync configs, puppetlabs'
   modulesync_config, example42), and a host of useful tools (linters,
   checkers, rspec-puppet, etc) newcomers to module development have to invest
   much to get to a fully-featured workflow. With the PDK, `pdk new module
   something` will get you going with the basic set today, without any further
   configuration necessary.
   - Based off the last point, *establishing a unified workflow*, and
   building a set of baseline recommendations.
   - *Focus and promotion of community efforts.* We really want to make
   sure that in the end as many folks as possible are using the broadest set
   of useful tools to improve their day-to-day work. The work you can see in
   v0.6, is only the first step on that road. Until then, at least there is
   `pdk bundle` so that all the tools that we currently do not support
   natively can still benefit from the pdk's runtime unchanged.


Bundling ruby was a good idea and all the gems.
>

Thank you :-)

Happy weekend, David

>
>
>
> Corey
>
>
> On Tuesday, August 8, 2017 at 7:58:39 PM UTC-7, Lindsey Smith wrote:
>>
>> I am happy to announce the release of version 0.6.0 of the Puppet
>> Development Kit (PDK) to the Puppet community. The open-source PDK
>> facilitates an easy, unified development workflow for Puppet modules, and
>> should appeal both to newcomers and experienced developers.
>>
>> For a list of enhancements and bug fixes since the 0.5.0 release, please
>> refer to the included CHANGELOG (https://github.com/puppetlabs
>> /pdk/blob/master/CHANGELOG.md#v060-2017-08-08).
>>
>> With the PDK you can:
>>
>>- Quickly get started with module development best practices and
>>tools to develop, test and publish high-quality Puppet modules with
>>confidence
>>- Shift quality to the left by catching issues earlier and faster,
>>before Puppet code is applied to live infrastructure
>>- Unit test modules from their workstation to ensure that Puppet code
>>is creating and managing resources as intended
>>
>> You can learn more about how to install and use the PDK by reviewing the
>> README (https://github.com/puppetlabs/pdk) or the Getting Started guide (
>> https://github.com/puppetlabs/pdk/blob/master/docs/pdk.md).
>>
>> OS native packages are available for a variety of platforms:
>>
>>- *Windows (7/10/2012/2016):* https://pupp
>>et-pdk.s3.amazonaws.com/pdk/0.6.0.0/repos/windows/pdk-0.6.0.0-x64.msi
>>
>> 
>>- *macOS 10.12 (Sierra):* https://puppet-pdk.s
>>3.amazonaws.com/pdk/0.6.0.0/repos/apple/10.12/PC1/x86_64/pdk
>>-0.6.0.0-1.osx10.12.dmg
>>
>> 
>>- *macOS 10.11 (El Capitan):* https://puppet-pdk.s
>>3.amazonaws.com/pdk/0.6.0.0/repos/apple/10.11/PC1/x86_64/pdk
>>-0.6.0.0-1.osx10.11.dmg
>>
>> 
>>- *RHEL 7:* https://puppet-pdk.s3.amazonaws.com/pdk/0.6.0.0/repos/el/
>>7/PC1/x86_64/pdk-0.6.0.0-1.el7.x86_64.rpm
>>
>> 
>>- *RHEL 6:* https://puppet-pdk.s3.amazonaws.com/pdk/0.6.0.0/repos/el/
>>6/PC1/x86_64/pdk-0.6.0.0-1.el6.x86_64.rpm
>>
>> 
>>- *SLES 12:* https://puppet-pdk.s3.amazonaws.com/pdk/0.6.0.0/repos/
>>sles/12/PC1/x86_64/pdk-0.6.0.0-1.sles12.x86_64.rpm
>>
>> 
>>- *SLES 11:* https://puppet-pdk.s3.amazonaws.com/pdk/0.6.0.0/repos/
>>sles/11/PC1/x86_64/pdk-0.6.0.0-1.sles11.x86_64.rpm
>>
>> 
>>-

Re: [Puppet-dev] Puppet Rspec - Check against Catalogue Value

2017-07-25 Thread David Schmitt

On 25 July 2017 at 00:21, James Perry  wrote:

> So I have a simple class, for now, where I am trying to write RSPEC tests
> to check the following:
>
> 1. Smart Parameter $current_version is in catalogue.
> 2. If $current_version = $installed_version (custom fact that will be
> stubbed as a :fact), that 'class foo' exits without doing anything.
> 3. if $current_version != $installed_version a class foo::cleanup is
> called.
>
> I have looked all over to try to work this out and keep hitting posts
> about "can't check variables" but when I do a p catalogue.resources I see:
>
> foo
> [Stage[main]{:name=>"main"}, Class[Settings]{:name=>"Settings"},
> Class[main]{:name=>"main"}, Class[Foo]{:name=>"Foo",
> :mypath=>"/opt/mypath", :current_ver=>"0.1.2"}]
>
> In foo.pp:
> class foo ( $mypath="/usr/local/mypath", $current_version="0.1.2" ) {
>   if $installed_version == $current_version { # Goodie. Nothing to do }
>   else { include foo::cleanup }
>
> }
>
> In the spec file .spec/classes/init_spec.rb:
> require 'spec_helper'
> describe 'foo' do
>context 'foo current version' do
>let :params do {
>:mypath => '/opt/mypath',
>   # :current_version => '1.2.3',
>}
> end
>
>it {p catalogue.resources}
>it do
>   is expected_to contain_class('foo').with(:current_version =>
> "0.1.2" )
>end
> end
>
> While this is very basic, and I have tried multiple ways, it error out
> with:
>  Failure/Error: should contain_class('epops_hyperic')
> .with_current_version("0.1.2")
>expected that the catalogue would contain Class[epops_hyperic] with
> current_version set to "0.1.2" but it is set to nil
>
> Yet the p catalogue.resources function shows the shows it correctly as
> noted in the Stage[main] above.
>
> If I uncomment the parameter :current_version => '1.2.3'  the catalogue
> print has :current_version => "1.2.3" as expected (since it is overridden)
> and the test fails with the expected message :current_ver set to "0.1.2"
> but it is set to "1.2.3". This I know how to deal with, but that then
> causes the problems with 2 and 3 above.
>
> What I want to test in the spec is if current_ver == expected version, the
> module doesn't need to do anything and exits. If not it will call class
> foo::cleanup. I read a lot on this today and have seen various generalized
> suggestions about 3, but nothing about 2.
>
> How do I test if the class exits after finding nothing is needed to be
> done or it included the class to do a cleanup accordingly?
>

Under the assumption that $installed_version is a fact, you can provide
stubbed fact values in your test setup. See
http://rspec-puppet.com/documentation/classes/#specifying-facts for details.

In your case, you then can have test cases for $installed_version, and
$current_version set to various different values and have your expectations
set up to expect, or not, the cleanup class:

context "when nothing to do" do
  let(:facts) {{ installed_version: '1.2.3' }}
  let(:params) {{ configured_version: '1.2.3' }}

  it { is_expected.not_to contain_class('foo::cleanup') }
end

context "when updating" do
  let(:facts) {{ installed_version: '1.0.0' }}
  let(:params) {{ configured_version: '1.2.3' }}

  it { is_expected.to contain_class('foo::cleanup') }
end

Cheers, David


>
> All of the tutorials give basics, but I can't find anything digging more
> specific that seems to work.
>
> Can anyone point me to the right places to look to research this?  So far
> the spec files seem really good for TDD, but without a good reference to
> these sorts of non file, package, service checks it is confusing.
>
> Thanks!
>
> --
> 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/aa734244-5887-485a-bb77-d88648b889de%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALF7fHY-k5BwiCDtqEaa-6wnAhL%3DGeAFXkmUti6w4xwQwi7_2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Steps to build a Puppet 4 install in my home directory for building modules

2017-07-24 Thread David Schmitt

On 19 July 2017 at 00:51, James Perry  wrote:

> Years ago there were a lot of docs about how to setup Puppet to allow
> someone to build modules outside having to have a master/client setup using
> puppet apply.
>
> I am trying to figure out the very cryptic world of spec/rspec, as it
> seems to not be documented very well anywhere for anyone other than someone
> that already knows it, In doing so I don't want to be able to develop in my
> home directory in a server versus having to develop modules and test with
> rspec against a full puppet server configuration.
>

The whole point of rspec is to not require a puppetserver for testing. You
can read more on the newly updated rspec-puppet tutorial at
http://rspec-puppet.com/tutorial/ .

If you need a development environment, we released a development kit
preview last week (
https://groups.google.com/d/msg/puppet-users/_G6issIdmVY/5oUfKhwkAQAJ )
that you might want to check out to get all the tools with a single
installer.

Would love to hear how you got along with either!

Cheers, David

>
> So far I have found little bits and pieces around, but nothing definitive
> or documented well for building something of this nature. The best I found
> so far were pre-built Ubuntu Docker containers or Vagrant builds. I don't
> have access to either presently or the time to build out a server to handle
> hosting either.
>
> Does anyone have a guide to setting up a stand-alone puppet client for
> development.  There used to be a rspec-puppet.com/setup page and that is
> what is linked from inside the documentation, but the page is gone.
>
> What I have so far is:
>
> 1. .Install puppet-agent to the host as root.
> 2. Setup paths to use the Ruby configuration from the puppet-agent so that
> the any gem add-ons are compatible with the version of the puppet-agent
> RPM.
> 3. Install puppetlabs-stdlib, rspec-puppet and any dependencies they
> require.
>
> When I have done a puppet module generate  and a rspec-puppet-init,
> I create a basic test to ensure the module compiles, as noted on the
> rspec-puppet Github page https://github.com/rodjek/rspec-puppet, That
> fails saying it can find compile.
>
> describe 'mymodule' do
>it { is_expected.to compile }
> end
>
> Any other tests that "should" work don't. either.
>
> So in modules/test/manifests/init.pp I have:
> class test {
>package { 'somepackage':
> ensure => present,
>   }
> }
>
> And my modules/test/spec/class/init_spec.rb has
>
> require 'spec_helper'
>
> describe 'test' do
> it { is_expected.to contain('somepackage').with_ensure('present')
> end
>
> So since this seems to be non-functional in my puppet development
> environment, which is a copy of my prod, I want to set it up fresh. When I
> tried in my home directory all i got were errors.
>
> --
> 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/23805142-d49e-4612-9590-472ab581dade%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALF7fHYL8%3DxK-vN-cTbiGcPJGvBFWBDsO9%3D-%2B8WfiXH2j52iew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] metadata.json ">= 1.x" version requirements

2017-05-30 Thread David Schmitt

On 30 May 2017 at 08:27, Dominic Cleal  wrote:

> 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.
>

+1

Cheers, David

>
> --
> 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.
>

-- 
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/CALF7fHboRWKCN8Gw8-3sn3oB0scsh%3DdtZf4K0Av7RyDRCtuN1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] File Management using puppet

2017-05-24 Thread David Schmitt

On 24 May 2017 at 15:16, ggun  wrote:

> Hi Experts,
>
> I need your help in below requirement.
> *Requirement*
> I need to create a file (xxx_logrotate.conf) with content as below
>
> /xx/xx/xx.log {
>
>  weekly
>
>  copytruncate
>
>  rotate 8
>
>  compress
>
> maxage 180
>
> missingok
>
> }
>
>
> 2. Create the symlink for above create file xxx_logrotate.conf to
> /etc/logrotate.d/xxx_logrotate.conf
>
>
> *My approach*
>
>
> 1. I went ahead creating the file with using erb tempalte for adding the
> file content but when I create a new resource to create the symlik for the
> source and target. The puppet run fails with duplicate file resource
>
>
>   file { 'xxx-log-rotation-config-file':
>
> ensure  => 'present',
>
> path=> '/xxx/conf/xxx_logrotate.conf',
>
> content => template('aaa/xxx_logrotate.conf.erb'),
>
> owner   => 'root',
>
> group   => 'root',
>
>   }
>
>
>   file { '/xxx/conf/xxx_logrotate.conf':
>
> ensure  => 'link',
>
> target  => '/etc/logrotate.d/xxx_logrotate.conf',
>
> require => File['xxx-log-rotation-config-file'],
>
>   }
>
>
> The puppet run fails for above code with below error
>
> Error: Evaluation Error: Error while evaluating a Resource Statement,
> Duplicate declaration: File[/xxx/conf/mysql_logrotate.conf] is already
> declared in file /etc/puppetlabs/code/environments/production/
> modules/xxx/manifests/postinstall.pp:46; cannot redeclare at
> /etc/puppetlabs/code/environments/production/modules/xxx/manifests/postinstall.pp:54
> at /etc/puppetlabs/code/environments/production/modules/xxx/manifests/
> postinstall.pp:54:3
>
>
>
>
You need to decide where you want the file, and where you want the symlink.
As it stands, you define the file /xxx/conf/xxx_logrotate.conf twice, once
with the templated content, once as symlink. In your situation, I'd switch
the title and target of the symlink around.


Cheers, David

-- 
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/CALF7fHbzDX8s2r8dvUS5jLcGpvXMYjJPcGD%2B%3D9oHhZuPOoY%3Dyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Need help installing .bin rpm file using puppet

2017-05-17 Thread David Schmitt

Hi Gaurav,

what are rpm.bin files? I've never heard of that before.

The first hit on google is a description of weird JDK packaging from
Oracle, where rpm.bin files are actually self-extracting shell scripts to
do their wretched license dance. If that is your use-case, I would run this
manually once on a scratch machine, capture the extracted RPM and use that
going forward.


Cheers, David

On 10 May 2017 at 04:12, gaurav gundal  wrote:

> Hi ,
>
> I am trying to manage the rpm.bin using puppet. I want to install the
> x.rpm.bin on the RHEL 7 using puppet, but puppet package cannot be used to
> install the .bin package directly.
> I have the file local on the server and I don't want to use and exec
> puppet resource to unpack bin and then use package.
> Is there any module to unpack the bin file so that I can then use the
> unpacked bin rpm as a pacakge.
>
> Thank you!
>
> --
> 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/fe267403-2f1c-4d8a-b0e9-7bbbc406bd5c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALF7fHY92HR3nwgqFjipHZ%3DKrEVMbOi6eboLiDmsH9xbK_2t%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-03-07 Thread David Schmitt

[aologies, this got lost in my Drafts folder.]

On 28 February 2017 at 19:35, Erik Dalén 
wrote:

> Overall I think this looks pretty good, but I have some questions and
> comments.
>
> For implementations that can't enumerate all existing resources (at least
> not in any fast way), like for example File, should they fine a get method
> that returns an empty hash, nil or just not define a get method? nil or not
> defining would allow special handling of them, so that would probably be
> preferable.
>
> But shouldn't it really have a way to fetch the state of a single resource
> in for those implementations? How would this otherwise handle something
> like "puppet resource file /path/to/file", traverse the entire file system
> and stat every file?
>

Yup it should. I've added a short discussion of the problem to the "Known
limitations" section. I could add verbiage around the get() method
returning nil (as opposed to []) to signal that there might be instances
available, but it's not possible to enumerate them.

> It seems it would also be handy with some helper method that compared
> current_state & target_state to filter out the changes that actually need
> to happen. I would imagine that sort of code would otherwise be duplicated
> in many implementations.
>

True. Porting the existing types and providers from our supported modules
is high on my list to validate the design, and will expose the patterns.
That'll make it much easier to build a library of helpers.

> logger.attribute_changed could really have a default value for message if
> the implementation provides attribute, old_value & new_value they shouldn't
> all need to supply "Changed #{attribute} from #{old_value} to #{new_value}
> ".
>

That's already specified.

> Will the attribute type fields be able to use type definitions shipped in
> the same module or present on in environment?
>

Currently anywhere "puppet 4 data types" are mentioned, only the built-in
types are usable. This is because the type information is required on the
agent, but puppet doesn't make it available yet. This work is tracked in
[PUP-7197](https://tickets.puppetlabs.com/browse/PUP-7197), but even once
that is implemented, modules will have to wait until the functionality is
widely available, before being able to rely on that.

> Will they be able to inspect the catalog or communicate between
> implementations, like in the concat & concat_fragment case?
>

 My preferred method to solve that would be a new top-level plugin, that
can inspect and change the catalog after it has been built. That plugin
could then collect all the fragments, and build a file resource from them,
before the catalog is even passed to the agent.

> Will they be able to generate resources? That could probably be done with
> something similar to the logger methods, but there is nothing like that in
> the proposal. I assume they won't have a generate method.
>

Adding more discrete functionality and life-cycle methods later seems like
an easy extension, that will not require a major API revision. Also
possibly another use-case for a catalog transform plugin.

> Will there be some requirement that these implementations are thread safe
> so puppet can start managing multiple resources in parallel? Or will they
> run in some subprocess even?
>
>
Theoretically, those implementations could be run in a separate process.
Looking at things like Lutterkort's libral, this might happen quicker than
I think today. As a firm believer of small incremental steps, I only want
to speculate on those things as far as I need to avoid blocking a future
change. Therefore I'm focusing this new API mostly on being small, self
contained, and decoupled.

Thanks for your time and work in reviewing this!

Regards, David

-- 
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/CALF7fHZBTSFdjrv12wfL3Qh6Fb1pzX0eZ-cL8ze-_YwcChf3jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-03-02 Thread David Schmitt

On 1 March 2017 at 14:12, Erik Dalén  wrote:

>
>
> On Wed, 1 Mar 2017 at 14:46 Trevor Vaughan  wrote:
>
>> As always, if I wait long enough, John will more eloquently provide the
>> response that I wanted to!
>>
>> I've added a few responses inline
>>
>>
>> *Big picture items*
>>
>> *Multiple implementations / implementation selection*
>>
>> In splitting resources into "definition" and "implementation", the
>> proposal adheres to a *form* similar to the current system's, but it
>> seems to have fundamentally different design goals.  I've always
>> interpreted the present type / provider system's separation of resource
>> interface from implementation first and foremost as a means to accommodate
>> multiple implementations. The one most appropriate to the target system is
>> chosen from among those available.  I think that's a sound design approach;
>> I like it, and it has served Puppet well.  As far as I can determine,
>> however, the proposal loses that completely -- I see no means to support
>> multiple implementations at all, much less means to match an implementation
>> to the target system.
>>
>>
>> I hadn't actually caught this, but if not just an oversight, it is indeed
>> concerning. The ability to choose from various providers has been a strong
>> play in Puppet's favor.
>>
>
> Although in some cases it is a bit annoying, for example not being able to
> install a gem and deb with the same name on a host. This specific case was
> fixed in https://tickets.puppetlabs.com/browse/PUP-1073 but still exists
> for other types than package.
> In many cases the providers actually manage different things, not mutually
> exclusive variants of the same thing.
> But having deb_package and rpm_package would definitely just be annoying
> if you wanted a module that works across multiple distros. Putting both
> providers into the same implementation file would be a bit ugly, but could
> work I guess.
>
>
>>
>>
>> *Inadequate interface documentation*
>>
>> As I said earlier, one of the biggest problems with the current system is
>> inadequate documentation.  As it now stands, the proposal's documentation
>> does about as well as the docs of the current system.  Missing is
>> information about how the runtime environment is intended to use the
>> defined objects and methods -- for example, under what circumstances it
>> will instantiate / invoke them, how many times per transaction (partially
>> addressed in the doc), at what point(s) in the transaction.  What may the
>> environment do with the object returned by get() and its contents (i.e.,
>> must implementations assume that the environment may modify them)?  Is
>> there anything the environment is required to do with them?  What may an
>> implementation do with the object passed to set() and its contents?  Is
>> there any expectation about relationships between the objects provided by
>> get() and received by put()?
>>
>>
>> This is definitely true. Gary's blog has been the seminal resource for
>> figuring out how to write types and providers and, instead of a new
>> interface, it might be good to finish the original docs. That said, I think
>> I remember David saying that part of the intent of this is to provide a
>> language-agnostic interface to managing the system so that users aren't
>> tightly bound to a particular implementation. I think that this is a good
>> goal *but* I would maintain compatibility with existing Type and Provider
>> implementations.
>>
>
> There's a bunch of things that can't be solved in any good way in the old
> type and provider system that looks like it would be pretty easy to solve
> in this new system. For example this old feature request:
> https://projects.puppetlabs.com/issues/2198
>

yeah, that is exactly the reason for passing an array of resources into the
set() method. It'll require more infrastructure around it, but we have to
start somewhere.


> *Specific features*
>>
>> *Attribute and parameter validation*
>>
>> Validation ought to be performed during catalog building, thus it needs
>> to be adequately addressed by type "definitions".  I am dissatisfied with
>> the proposal's provision for that.  The Puppet type system is very
>> expressive, but it can also be very arcane.  I maintain that it is a
>> mistake to rely exclusively on the type system for validating "attributes"
>> or "operational parameters".  Moreover, I think the proposal is missing an
>> opportunity to provide for multiple-attribute, multiple-parameter
>> covalidation.  This has been requested on and off for a long time, and this
>> proposal is a great opportunity to finally put it in place.
>>
>>
>> This was one of my biggest worries early on and it has been solidified
>> with the example code. The Type system simply isn't suitable for complex
>> validation at this point. I need logic (sometimes stupid amounts of logic)
>> and, until I can do arbitrary validation with the Type system, I can't use

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-03-02 Thread David Schmitt

On 1 March 2017 at 13:46, Trevor Vaughan  wrote:

> As always, if I wait long enough, John will more eloquently provide the
> response that I wanted to!
>
> I've added a few responses inline
>
>
> *Big picture items*
>>
>> *Multiple implementations / implementation selection*
>>
>> In splitting resources into "definition" and "implementation", the
>> proposal adheres to a *form* similar to the current system's, but it
>> seems to have fundamentally different design goals.  I've always
>> interpreted the present type / provider system's separation of resource
>> interface from implementation first and foremost as a means to accommodate
>> multiple implementations. The one most appropriate to the target system is
>> chosen from among those available.  I think that's a sound design approach;
>> I like it, and it has served Puppet well.  As far as I can determine,
>> however, the proposal loses that completely -- I see no means to support
>> multiple implementations at all, much less means to match an implementation
>> to the target system.
>>
>>
> I hadn't actually caught this, but if not just an oversight, it is indeed
> concerning. The ability to choose from various providers has been a strong
> play in Puppet's favor.
>

See my answer to John's point.


>
>
>> *Inadequate interface documentation*
>>
>> As I said earlier, one of the biggest problems with the current system is
>> inadequate documentation.  As it now stands, the proposal's documentation
>> does about as well as the docs of the current system.  Missing is
>> information about how the runtime environment is intended to use the
>> defined objects and methods -- for example, under what circumstances it
>> will instantiate / invoke them, how many times per transaction (partially
>> addressed in the doc), at what point(s) in the transaction.  What may the
>> environment do with the object returned by get() and its contents (i.e.,
>> must implementations assume that the environment may modify them)?  Is
>> there anything the environment is required to do with them?  What may an
>> implementation do with the object passed to set() and its contents?  Is
>> there any expectation about relationships between the objects provided by
>> get() and received by put()?
>>
>>
> This is definitely true. Gary's blog has been the seminal resource for
> figuring out how to write types and providers and, instead of a new
> interface, it might be good to finish the original docs. That said, I think
> I remember David saying that part of the intent of this is to provide a
> language-agnostic interface to managing the system so that users aren't
> tightly bound to a particular implementation. I think that this is a good
> goal *but* I would maintain compatibility with existing Type and Provider
> implementations.
>

Existing types will not go away for a long time. My prototype
translates attributes into newproperty calls and shoves the get methods
into a 3.x type. For everyone else in the agent or server this will look
and behave exactly like a 3.x type.


>
> I've also put in requests for the ability to maintain global state across
> the catalog compilation. If the brunt of the work is moved to the client,
> this may be more feasible but I think that it's perfectly possible in the
> current system with a namespaced caching system.
>

I've discussed this, and possible solutions in my answer to John.


>
> Also, I would like to see the resource utilization on the clients made
> better and maybe this can be addressed during the update.
>

This interface provides the possibility for batching. The current agent
runtime obviously cannot take advantage of that yet, but it is a chicken
and egg issue. Getting this going would be a huge payoff.

*Pushing new responsibilities onto resource implementations*
>>
>> The minimalistic approach to defining the interface for resource
>> implementations has the inevitable effect of making the host environment
>> incapable of some of the tasks that it presently performs, leaving the onus
>> on resource implementations to fill the gaps.  For example, since there is
>> no way for the environment to retrieve the state of a specified individual
>> resource, and because some resource types cannot feasibly be enumerated,
>> the environment cannot, in general, determine whether resources are in
>> sync.  Only resource implementations can be relied upon to do that, and
>> then only in the context of their put() methods.
>>
>
> I'm assuming (possibly incorrectly) that there would be a standard Ruby
> back end example provided. I'll also throw down the gauntlet and say that
> it should be the File resource. Being one of the oldest, and most janky,
> native types, I feel that it should be the seminal example. If you do
> 'easy' ones, I'll look at this askance, if you tackle (and improve) the
> core types, I'll have something solid to reference.
>

The v1 is not intended to solve all the nastiness that is required for the

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-03-02 Thread David Schmitt

On 28 February 2017 at 17:07, John Bollinger <john.bollin...@stjude.org>
wrote:

>
>
> On Monday, February 27, 2017 at 8:59:46 AM UTC-6, David Schmitt wrote:
>>
>> Hi folks,
>>
>> I've written down the design in README format now. This should make for a
>> easier to ingest from a module developer's perspective. Meanwhile I've also
>> had a shot at a hardcoded implementation of this, and it is technically
>> possible to implement this too.
>>
>
>
> Thanks for your efforts on this documentation.  It helps clarify your
> view.  I think you have some good ideas here, but I also think that what
> you've presented, as you've presented it, is not a viable replacement for
> the type & provider system we have now.  Moreover, there remain important
> areas that I would dearly love to see documented, and one or two longtime
> sore spots that this proposal seems to be missing the opportunity to
> address.
>

This is only a v1. It is presented with the intent to build a simpler, more
approachable foundation for future work.


> *Big picture items*
>
> *Multiple implementations / implementation selection*
>
> In splitting resources into "definition" and "implementation", the
> proposal adheres to a *form* similar to the current system's, but it
> seems to have fundamentally different design goals.  I've always
> interpreted the present type / provider system's separation of resource
> interface from implementation first and foremost as a means to accommodate
> multiple implementations. The one most appropriate to the target system is
> chosen from among those available.  I think that's a sound design approach;
> I like it, and it has served Puppet well.  As far as I can determine,
> however, the proposal loses that completely -- I see no means to support
> multiple implementations at all, much less means to match an implementation
> to the target system.
>

Looking at which types provide multiple implementations, I mostly found
types from core puppet. Even looking at those (e.g. package, user,
service), they have many attributes that are provider specific, making the
abstractions very leaky. Other examples in the wider software world  (e.g.
SQL mappers, vendor-independent configuration schemes) also highlight the
issues with one-size-fits-all approaches: to get the most out of a specific
system, users require full access to the lower layer's capabilities. Having
said that, it does not invalidate the use-cases where a broad applicability
trumps those special cases. Puppet already has a perfectly reasonable DSL
to deal with those cases. For example, a hypothetical successor to the
package type could look like this:

define package (
  Ensure $ensure,
  Enum[apt, rpm] $provider, # have a hiera 5 dynamic binding to a function
choosing a sensible default for the current system
  Optional[String] $source  = undef,
  Optional[String] $version = undef,
  Optional[Hash] $options   = { },
) {
  case $provider {
apt: {
  package_apt { $title:
ensure  => $ensure,
source  => $source,
version => $version,
*   => $options,
  }
}
rpm: {
  package_rpm { $title:
ensure => $ensure,
source => $source,
*  => $options,
  }
  if defined($version) { fail("RPM doesn't support \$version") }
  # ...
}
  }
}

This would provide a best of both worlds approach that exposes the
subtleties of particular systems, and the full use of those features,
without overloading a common interface, while still providing a quick and
simple top-level entry point, if you don't need that level of detail.


> *Inadequate interface documentation*
>
> As I said earlier, one of the biggest problems with the current system is
> inadequate documentation.  As it now stands, the proposal's documentation
> does about as well as the docs of the current system.
>

Thank you for this praise, seeing as I'm up against a team of world-class
tech writers, and legends like Dan Bode :-D


>   Missing is information about how the runtime environment is intended to
> use the defined objects and methods -- for example, under what
> circumstances it will instantiate / invoke them, how many times per
> transaction (partially addressed in the doc), at what point(s) in the
> transaction.  What may the environment do with the object returned by
> get() and its contents (i.e., must implementations assume that the
> environment may modify them)?  Is there anything the environment is
> required to do with them?  What may an implementation do with the object
> passed to set() and its contents?  Is there any expectation about
> relationships between the objects provided by get() and received by put()?
>

Very

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-03-02 Thread David Schmitt

On 28 February 2017 at 21:31, Shawn Ferry <shawn.fe...@oracle.com> wrote:

>
> On Feb 28, 2017, at 12:54 PM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
>
>
> On 28 February 2017 at 16:34, Shawn Ferry <shawn.fe...@oracle.com> wrote:
>
>>
>>
>>
>>
>> --
>> Shawn Ferry
>> On Feb 28, 2017, at 10:59, David Schmitt <david.schm...@puppet.com>
>> wrote:
>>
>>
>>
>> On 27 February 2017 at 18:57, Shawn Ferry <shawn.fe...@oracle.com> wrote:
>>
>>>
>>> On Feb 27, 2017, at 9:59 AM, David Schmitt <david.schm...@puppet.com>
>>> wrote:
>>>
>>> Commands
>>>
>>> To use CLI commands in a safe and comfortable manner, the implementation
>>> can use the commands method to access shell commands. You can either
>>> use a full path, or a bare command name. In the latter case puppet will use
>>> the system PATH setting to search for the command. If the commands are not
>>> available, an error will be raised and the resources will fail in this run.
>>> The commands are aware of whether noop is in effect or not, and will skip
>>> the actual execution if necessary.
>>>
>>> Puppet::ResourceImplementation.register('apt_key') do
>>>   commands apt_key: '/usr/bin/apt-key'
>>>   commands gpg: 'gpg'
>>>
>>> This will create methods called apt_get, and gpg, which will take CLI
>>> arguments without any escaping, and run them in a safe environment (clean
>>> working directory, clean environment). For example to call apt-key to
>>> delete a specific key by id:
>>>
>>> If the goal here is safe execution shouldn’t it escape at least shell
>>> special characters? My concern is based on some of the providers I work on
>>> which take free form strings as arguments and any type that doesn’t fully
>>> validate or munge inputs.
>>>
>>> There is a risk that any provider* today can suffer from shell command
>>> injection. It seems that using shelljoin on the argument array would be
>>> useful or shellesacpe on each element. However, for a simplified API it
>>> seems that it could be done more centrally here instead of pushing it to
>>> each implementation to make sure it is done if needed.
>>>
>>> * That can’t exclude shell characters and doesn’t munge input to escape
>>> them.
>>>
>>
>> The trick is to not use system() which calls through the shell, but the
>> array variant of spawn() or popen() that doesn't go through a shell. Not
>> only will that be much better performing due to fewer binaries being
>> loaded, but also eliminates all shell parsing from the call chain. Having
>> this wrapped up in the API as the primary mechanism to call CLI commands is
>> intended to help people with that, instead of having them have to find the
>> right ruby incantation themselves.
>>
>>
>> At what point does Puppet::Util::Execution.execute change behavior?
>>
>> RTFM 4.x is an acceptable answer I only just got 4.7 integrated into our
>> environment but glancing at the code doesn't seem to do anything other than
>> Kernel.exec
>>
>> https://github.com/puppetlabs/puppet/blob/e39b265ef0b34644bb
>> 645b4f6674c257ddaa75fa/lib/puppet/util/execution.rb#L268
>>
>
> As an existing API, we won't be able to change that quickly. Such a change
> is also not really in scope for the resource API proposal. I would
> recommend against using any Puppet::* APIs in new providers, to reduce
> dependencies to the main puppet code. That's why  the `commands` DSL has
> made it into the new proposal, to provide a more "local" way to call
> commands.
>
>
> I’m not calling Puppet::Util::Execution.execute directly. Using defined
> commands results in a Kernel.exec call.
>
> commands echo: “echo”
> echo(“This does bad things;echo this does bad things | wall")
>
> It’s something I’ve been thinking about making a pull for but I think the
> scope of the change is broad enough that the testing more complicated than
> I can commit to. I also think it’s a desirable or likely used behavior for
> Exec calls where it should probably still be allowed.
>
> In any case I’m stuck on the single point when it’s really a broader
> issue. My main point is that it command input could change before being
> sent onto the existing API for execution here so all new development under
> this implementation can take advantage of it by default.
>

Yup. The new API will only accept array input.


Cheers, David


>
>
> Thanks
> Shawn

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-02-28 Thread David Schmitt

On 28 February 2017 at 16:34, Shawn Ferry <shawn.fe...@oracle.com> wrote:

>
>
>
>
> --
> Shawn Ferry
> On Feb 28, 2017, at 10:59, David Schmitt <david.schm...@puppet.com> wrote:
>
>
>
> On 27 February 2017 at 18:57, Shawn Ferry <shawn.fe...@oracle.com> wrote:
>
>>
>> On Feb 27, 2017, at 9:59 AM, David Schmitt <david.schm...@puppet.com>
>> wrote:
>>
>> Commands
>>
>> To use CLI commands in a safe and comfortable manner, the implementation
>> can use the commands method to access shell commands. You can either use
>> a full path, or a bare command name. In the latter case puppet will use the
>> system PATH setting to search for the command. If the commands are not
>> available, an error will be raised and the resources will fail in this run.
>> The commands are aware of whether noop is in effect or not, and will skip
>> the actual execution if necessary.
>>
>> Puppet::ResourceImplementation.register('apt_key') do
>>   commands apt_key: '/usr/bin/apt-key'
>>   commands gpg: 'gpg'
>>
>> This will create methods called apt_get, and gpg, which will take CLI
>> arguments without any escaping, and run them in a safe environment (clean
>> working directory, clean environment). For example to call apt-key to
>> delete a specific key by id:
>>
>> If the goal here is safe execution shouldn’t it escape at least shell
>> special characters? My concern is based on some of the providers I work on
>> which take free form strings as arguments and any type that doesn’t fully
>> validate or munge inputs.
>>
>> There is a risk that any provider* today can suffer from shell command
>> injection. It seems that using shelljoin on the argument array would be
>> useful or shellesacpe on each element. However, for a simplified API it
>> seems that it could be done more centrally here instead of pushing it to
>> each implementation to make sure it is done if needed.
>>
>> * That can’t exclude shell characters and doesn’t munge input to escape
>> them.
>>
>
> The trick is to not use system() which calls through the shell, but the
> array variant of spawn() or popen() that doesn't go through a shell. Not
> only will that be much better performing due to fewer binaries being
> loaded, but also eliminates all shell parsing from the call chain. Having
> this wrapped up in the API as the primary mechanism to call CLI commands is
> intended to help people with that, instead of having them have to find the
> right ruby incantation themselves.
>
>
> At what point does Puppet::Util::Execution.execute change behavior?
>
> RTFM 4.x is an acceptable answer I only just got 4.7 integrated into our
> environment but glancing at the code doesn't seem to do anything other than
> Kernel.exec
>
> https://github.com/puppetlabs/puppet/blob/e39b265ef0b34644bb645b4f6674c2
> 57ddaa75fa/lib/puppet/util/execution.rb#L268
>

As an existing API, we won't be able to change that quickly. Such a change
is also not really in scope for the resource API proposal. I would
recommend against using any Puppet::* APIs in new providers, to reduce
dependencies to the main puppet code. That's why  the `commands` DSL has
made it into the new proposal, to provide a more "local" way to call
commands.

Cheers, David

-- 
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/CALF7fHaPBLuZDzHOV2OSrK_tJQWsFjn%3DK2apdXmRBnN18uUQJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-02-28 Thread David Schmitt

On 27 February 2017 at 18:57, Shawn Ferry <shawn.fe...@oracle.com> wrote:

>
> On Feb 27, 2017, at 9:59 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
> Commands
>
> To use CLI commands in a safe and comfortable manner, the implementation
> can use the commands method to access shell commands. You can either use
> a full path, or a bare command name. In the latter case puppet will use the
> system PATH setting to search for the command. If the commands are not
> available, an error will be raised and the resources will fail in this run.
> The commands are aware of whether noop is in effect or not, and will skip
> the actual execution if necessary.
>
> Puppet::ResourceImplementation.register('apt_key') do
>   commands apt_key: '/usr/bin/apt-key'
>   commands gpg: 'gpg'
>
> This will create methods called apt_get, and gpg, which will take CLI
> arguments without any escaping, and run them in a safe environment (clean
> working directory, clean environment). For example to call apt-key to
> delete a specific key by id:
>
> If the goal here is safe execution shouldn’t it escape at least shell
> special characters? My concern is based on some of the providers I work on
> which take free form strings as arguments and any type that doesn’t fully
> validate or munge inputs.
>
> There is a risk that any provider* today can suffer from shell command
> injection. It seems that using shelljoin on the argument array would be
> useful or shellesacpe on each element. However, for a simplified API it
> seems that it could be done more centrally here instead of pushing it to
> each implementation to make sure it is done if needed.
>
> * That can’t exclude shell characters and doesn’t munge input to escape
> them.
>

The trick is to not use system() which calls through the shell, but the
array variant of spawn() or popen() that doesn't go through a shell. Not
only will that be much better performing due to fewer binaries being
loaded, but also eliminates all shell parsing from the call chain. Having
this wrapped up in the API as the primary mechanism to call CLI commands is
intended to help people with that, instead of having them have to find the
right ruby incantation themselves.



Cheers, David

-- 
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/CALF7fHbvi5wbFxuARSQYadwUD25-yN7VN8mksm3Hqm%2Bj98AUnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-02-27 Thread David Schmitt

Hi folks,

I've written down the design in README format now. This should make for a
easier to ingest from a module developer's perspective. Meanwhile I've also
had a shot at a hardcoded implementation of this, and it is technically
possible to implement this too.

---
Resource API

A *resource* is the basic thing that is managed by puppet. Each resource
has a set of attributes describing its current state. Some of the
attributes can be changed throughout the life-time of the resource, some
attributes only report back, but cannot be changed (see read_only)others
can only be set once during initial creation (see init_only). To gather
information about those resources, and to enact changes in the real world,
puppet requires a piece of code to *implement* this interaction. The
implementation can have parameters that influence its mode of operation
(see operational_parameters). To describe all these parts to the
infrastructure, and the consumers, the resource *Definition* (f.k.a.
'type') contains definitions for all of them. The *Implementation* (f.k.a.
'provider') contains code to *get* and *set* the system state.
Resource
Definition

Puppet::ResourceDefinition.register(
name: 'apt_key',
docs: <<-EOS,  This type provides Puppet with the capabilities
to manage GPG keys needed  by apt to perform package validation.
Apt has it's own GPG keyring that can  be manipulated through the
`apt-key` command.  apt_key {
'6F6B15509CF8E59E6E469F327F438280EF8D349F':source =>
'http://apt.puppetlabs.com/pubkey.gpg'  }  **Autorequires**:
   If Puppet is given the location of a key file which looks like an
absolute  path this type will autorequire that file.EOS
attributes:   {
ensure:  {
type: 'Enum[present, absent]',
docs: 'Whether this apt key should be present or absent on
the target system.'
},
id:  {
type:'Variant[Pattern[/\A(0x)?[0-9a-fA-F]{8}\Z/],
Pattern[/\A(0x)?[0-9a-fA-F]{16}\Z/],
Pattern[/\A(0x)?[0-9a-fA-F]{40}\Z/]]',
docs:'The ID of the key you want to manage.',
namevar: true,
},
# ...
created: {
type:  'String',
docs:  'Date the key was created, in ISO format.',
read_only: true,
},
},
autorequires: {
file:'$source', # will evaluate to the value of the
`source` attribute
package: 'apt',
},
)

The Puppet::ResourceDefinition.register(options) function takes a Hash with
the following top-level keys:

   - name: the name of the resource. For autoloading to work, the whole
   function call needs to go into lib/puppet/type/.rb.
   - docs: a doc string that describes the overall working of the type,
   gives examples, and explains pre-requisites as well as known issues.
   - attributes: an hash mapping attribute names to their details. Each
   attribute is described by a hash containing the puppet 4 data type, a
   docs string, and whether the attribute is the namevar, read_only, and/or
   init_only.
   - operational_parameters: a hash mapping parameter names to puppet data
   types and docs strings.
   - autorequires, autobefore, autosubscribe, and autonotify: a Hash
   mapping resource types to titles. Currently the titles must either be
   constants, or, if the value starts with a dollar sign, a reference to the
   value of an attribute.

Resource
Implementation

At runtime the current and intended system states for a single resource
instance are always represented as ruby Hashes of the resource's
attributes, and applicable operational parameters.

The two fundamental operations to manage resources are reading and writing
system state. These operations are implemented in the ResourceImplementation
as get and set:

Puppet::ResourceImplementation.register('apt_key') do
  def get
[
  'title': {
name: 'title',
# ...
  },
]
  end

  def set(current_state, target_state, noop: false)
target_state.each do |title, resource|
  # ...
end
  endend

The get method returns a Hash of all resources currently available, keyed
by their title. If the get method raises an exception, the implementation
is marked as unavailable during the current run, and all resources of its
type will fail. The error message will be reported to the user.

The set method updates resources to the state defined in target_state. For
convenience, current_state contains the last available system state from a
prior get call. When noop is set to true, the implementation must not
change the system state, but only report what it would change.
Runtime
Environment

The primary runtime

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-02-08 Thread David Schmitt

On 7 February 2017 at 17:13, jcbollinger <john.bollin...@stjude.org> wrote:

>
>
> On Tuesday, January 31, 2017 at 10:04:27 AM UTC-6, David Schmitt wrote:
>>
>>
>> The type and provider API has been the bane of my existence since I
>> [started writing native resources](https://github.com/
>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>>
>
>
> Honestly, I've never thought the type / provider system was too bad.
> Certainly it works pretty well for simple things.  Now, I'm more of a Dev
> who does Ops than an Op who Devs, but from my perspective, the biggest
> problem with Puppet's types & providers has always been inadequate
> documentation.  The docs in this area are a bit better now than when I
> started with Puppet around eight years ago, but they have always missed
> presenting many relevant details about how the host Puppet instance,
> resource instances, and their associated provider instances interact.
>

What I read here is that the current state is complex enough that a couple
of books and a crack team of tech writers couldn't explain it well.

>   This new effort doesn't seem to be targeting any of that.
>

Looping back to the "lack of documentation", I see this lack grounded
partially in the huge surface area that needs to be covered, since the
existing T API is deeply entangled into the catalog compilation, and the
agent transactions.

This new API has two entry points that take a small number of easily
explained arguments, making a full documentation realistic. From this (and
other's) reaction I do understand now, that I should have started with a
more README-driven approach, to highlight the difference more. Let's try
this again:

The *SimpleResource* (working title) consists of three distinct, but
cooperating parts. The *Definition* describes the shape of a resource, its
attributes, their types, which is the namevar, and the doc strings. The *get
method* returns a list of hashes, each matching the shape of the resource
as defined in the Definition. For example, a list of apt_key resources
(here rendered in JSON) would look like this:

[
  {
"name": "BBCB188AD7B3228BCF05BD554C0BE21B5FF054BD",
"ensure": "present",
"fingerprint": "BBCB188AD7B3228BCF05BD554C0BE21B5FF054BD",
"long": "4C0BE21B5FF054BD",
"short": "5FF054BD",
"size": "2048",
"type": "rsa",
"created": "2013-06-07 23:55:31 +0100",
"expiry": null,
"expired": false
  },
  {
"name": "B71ACDE6B52658D12C3106F44AB781597254279C",
"ensure": "present",
"fingerprint": "B71ACDE6B52658D12C3106F44AB781597254279C",
"long": "4AB781597254279C",
"short": "7254279C",
"size": "1024",
"type": "dsa",
"created": "2007-03-08 20:17:10 +",
"expiry": null,
"expired": false
  },
  ...

The *set method* takes a list of target goals in the same format and is
responsible for enforcing those goals on the target system. When calling
the set method, the caller may provide the current state (as received from
a recent get call) to allow the set method to shortcut reading the existing
state again. The basic pattern for the set method looks like this:

def set(current_state, target_state, noop = false)
  existing_keys = Hash[current_state.collect { |k| [k[:name], k] }]
  target_state.each do |resource|
# additional validation for this resource goes here

current = existing_keys[resource[:name]]
if current && resource[:ensure].to_s == 'absent'
  # delete the resource
elsif current && resource[:ensure].to_s == 'present'
  # update the resource
elsif !current && resource[:ensure].to_s == 'present'
  # create the resource
end
  end
end

> Now, finally, we'll do something about it. I'm currently working on
>> designing a nicer API for types and providers. My primary goals are to
>> provide a smooth and simple ruby developer experience for both scripters
>> and coders. Secondary goals were to eliminate server side code, and make
>> puppet 4 data types available. Currently this is completely aspirational
>> (i.e. no real code has been written), but early private feedback was
>> encouraging.
>>
>>
>
> I'm confused and dubious: how is it that the guiding goals for this effort
> are all about form rather than function?  Surely, if you intend for the
> result to serve any particular function(s) then you need to be guided at
> least in part by which functions those are.  Perhaps for

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-02-07 Thread David Schmitt

On 7 February 2017 at 10:44, Thomas Hallgren <thomas.hallg...@puppet.com>
wrote:

> Like Martin Afke above, I'm very interested in what could be done using
> the Puppet Language alone. What use cases can be covered entirely that way?
>

As David L pointed out, many of these things can be done today in defines,
or classes, already.

What is not feasible to ever do with PL?
>

Talk to external APIs.


> Would an API that made it possible to write types and providers PL and
> hand over tiny tasks to another language (Ruby, C, Go, etc.) be of
> interest? I.e. a clean cut boundary between the things possible
> (appropriate) to implement with PL and the things that aren't?
>

I do not understand how extending the puppet dsl on the server helps with
resource management on the agent.


> Perhaps this is a first step in that direction?
>

In one possible reading, types are already are a extension point of the
DSL, and this proposal makes that less painful, and easier to reason about.

Cheers, David

PS: If anyone is at ConfigurationManagementCamp in Gent these days, hit me
up to talk about this!



>
> - thomas
>
>
> On Tue, Feb 7, 2017 at 11:31 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
>> Hi Corey,
>>
>> thanks for looking into this. I've been travelling so accept my apologies
>> for a late answer.
>>
>>
>> On 5 February 2017 at 20:52, Corey Osman <co...@logicminds.biz> wrote:
>>
>>> One improvement I would like to see with the provider API is around
>>> getting the current state.  I see many beginners including myself trying to
>>> add way more complexity than required in the exists? method.
>>>
>>> One would think that you in order to figure out if the resource exists
>>> that you should just query the system and DIY.  And I'll pick on my own
>>> code as an example: https://github.com/logicminds/
>>> bmclib/blob/0.1.0/lib/puppet/provider/bmc/ipmitool.rb#L34
>>>
>>> However, this is not the case.  This is the exact opposite of what you
>>> need to do. Instead you need to query the API which is hard to understand
>>> and not obvious at first because instinct tells you to get the state
>>> yourself.
>>>
>>> https://github.com/logicminds/bmclib/blob/master/lib/puppet/
>>> provider/bmc/ipmitool.rb#L60
>>>
>>> Another improvement which I hope would get addressed is self.prefetch.
>>> While self.instances is pretty simple to understand the prefetch method
>>> could probably use a better name and an easier way to implement. It was not
>>> obvious at first how to implement. So many people don't implement these two
>>> methods when they should making their provider more useful.
>>>
>>
>> Exactly what this should address. The implementation of `get` is very
>> straightforward (and, currently, required).
>>
>> The type checking looks pretty amazing and simple to understand and
>>> implement in the type code.
>>>
>>
>> Thanks! I hope that a provider author would never have to "implement"
>> this. The SimpleResource will create a proper Type class underneath with
>> all the validation and munging generated.
>>
>>
>>
>>>
>>> Additionally, As Trevor mentioned I also have some projects
>>> (puppet-debugger and puppet-retrospec) that utilize the current Puppet API
>>> to introspec resources and query the catalog please so make sure this new
>>> code doesn't break my projects.   I'll be happy to test out any new API for
>>> third party compatibility.
>>>
>>
>> Thanks for the offer! For the time being, the implementation will sit
>> completely on top of the unmodified puppet code to work on all puppet 4
>> versions out there. I also don't expect existing types to switch
>> immediately, but I do hope that the new API makes implementations so much
>> easier that people will switch quickly.
>>
>> Then it will be a matter of filling in the gaps for the special cases.
>>
>> Cheers, David S
>>
>>
>>
>>>
>>>
>>> Corey  (NWOps)
>>>
>>>
>>>
>>> On Tuesday, January 31, 2017 at 8:04:19 AM UTC-8, David Schmitt wrote:
>>>>
>>>> Hi *,
>>>>
>>>> The type and provider API has been the bane of my existence since I
>>>> [started writing native resources](https://github.com/
>>>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>>>> Now, finally, we'll do something about it. I'm currently working on
>

Re: [Puppet-dev] Re: Draft for new type and provider API

2017-02-07 Thread David Schmitt

Hi Corey,

thanks for looking into this. I've been travelling so accept my apologies
for a late answer.


On 5 February 2017 at 20:52, Corey Osman <co...@logicminds.biz> wrote:

> One improvement I would like to see with the provider API is around
> getting the current state.  I see many beginners including myself trying to
> add way more complexity than required in the exists? method.
>
> One would think that you in order to figure out if the resource exists
> that you should just query the system and DIY.  And I'll pick on my own
> code as an example: https://github.com/logicminds/
> bmclib/blob/0.1.0/lib/puppet/provider/bmc/ipmitool.rb#L34
>
> However, this is not the case.  This is the exact opposite of what you
> need to do. Instead you need to query the API which is hard to understand
> and not obvious at first because instinct tells you to get the state
> yourself.
>
> https://github.com/logicminds/bmclib/blob/master/lib/puppet/
> provider/bmc/ipmitool.rb#L60
>
> Another improvement which I hope would get addressed is self.prefetch.
> While self.instances is pretty simple to understand the prefetch method
> could probably use a better name and an easier way to implement. It was not
> obvious at first how to implement. So many people don't implement these two
> methods when they should making their provider more useful.
>

Exactly what this should address. The implementation of `get` is very
straightforward (and, currently, required).

The type checking looks pretty amazing and simple to understand and
> implement in the type code.
>

Thanks! I hope that a provider author would never have to "implement" this.
The SimpleResource will create a proper Type class underneath with all the
validation and munging generated.



>
> Additionally, As Trevor mentioned I also have some projects
> (puppet-debugger and puppet-retrospec) that utilize the current Puppet API
> to introspec resources and query the catalog please so make sure this new
> code doesn't break my projects.   I'll be happy to test out any new API for
> third party compatibility.
>

Thanks for the offer! For the time being, the implementation will sit
completely on top of the unmodified puppet code to work on all puppet 4
versions out there. I also don't expect existing types to switch
immediately, but I do hope that the new API makes implementations so much
easier that people will switch quickly.

Then it will be a matter of filling in the gaps for the special cases.

Cheers, David S



>
>
> Corey  (NWOps)
>
>
>
> On Tuesday, January 31, 2017 at 8:04:19 AM UTC-8, David Schmitt wrote:
>>
>> Hi *,
>>
>> The type and provider API has been the bane of my existence since I
>> [started writing native resources](https://github.com/
>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>> Now, finally, we'll do something about it. I'm currently working on
>> designing a nicer API for types and providers. My primary goals are to
>> provide a smooth and simple ruby developer experience for both scripters
>> and coders. Secondary goals were to eliminate server side code, and make
>> puppet 4 data types available. Currently this is completely aspirational
>> (i.e. no real code has been written), but early private feedback was
>> encouraging.
>>
>> To showcase my vision, this [gist](https://gist.github.com
>> /DavidS/430330ae43ba4b51fe34bd27ddbe4bc7) has the [apt_key type](
>> https://github.com/puppetlabs/puppetlabs-apt/blob/
>> master/lib/puppet/type/apt_key.rb) and [provider](https://github.com/
>> puppetlabs/puppetlabs-apt/blob/master/lib/puppet/provider/
>> apt_key/apt_key.rb) ported over to my proposal. The second example there
>> is a more long-term teaser on what would become possible with such an API.
>>
>> The new API, like the existing, has two parts: the implementation that
>> interacts with the actual resources, a.k.a. the provider, and information
>> about what the implementation is all about. Due to the different usage
>> patterns of the two parts, they need to be passed to puppet in two
>> different calls:
>>
>> The `Puppet::SimpleResource.implement()` call receives the
>> `current_state = get()` and `set(current_state, target_state, noop)`
>> methods. `get` returns a list of discovered resources, while `set` takes
>> the target state and enforces those goals on the subject. There is only a
>> single (ruby) object throughout an agent run, that can easily do caching
>> and what ever else is required for a good functioning of the provider. The
>> state descriptions passed around are simple lists of key/value hashes
>> describing resources. This will allow the implementatio

Re: [Puppet-dev] Draft for new type and provider API

2017-02-03 Thread David Schmitt

On 3 February 2017 at 11:12, Martin Alfke  wrote:

> Hi David,
>
> many thanks for sharing your ideas.
>
> As you already know: personally I don’t say that types and providers are
> way to difficult.
> It is more a matter on how to explain them.
> I will dig through your document during weekend. We can have a chat on
> Monday in Ghent.
>
> But besides this:
> is your idea somehow related to the libral project?
> https://github.com/puppetlabs/libral
>
>
>

>
>   * It maps 1:1 to the capabilities of PCore, and is similar to the libral
> interface description (see [libral#1](https://github.com/
> puppetlabs/libral/pull/2)). This ensures future interoperability between
> the different parts of the ecosystem.
>
>
libral is a neighbouring project, with its own set of distinct design
goals. Staying bidirectionally compatible is a necessary requisite for this
proposal here. (Which can be handled on both sides, depending on a wide
variety of things).

Cheers, David

-- 
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/CALF7fHb9b7HknTGrhMbu5213kpMX3rHg-nwiOKr2jvcqnzTh-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Draft for new type and provider API

2017-02-02 Thread David Schmitt

On 2 February 2017 at 15:38, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:

> I think I'm slowly talking myself into this.
>
> The issue that I've had is that the current Data Types are composable.
> There's a ticket open about it and hopefully that will fix a lot of my
> issues.
>

Assuming you're talking about PUP-7033, there is nothing much I can help
you with there.

> Unfortunately, it looks like my heap/stack discussion was with Henrik on
> Slack, so that's not super helpful.
>
> Basically, the idea is that, instead of using a pure object model, objects
> would be created *as necessary* and the linear execution model would be
> kept in a simple array (stack). The data space (heap) would contain the
> attributes that are required for each object to execute.
>
> This means that the data structure would be extremely efficient and there
> would be almost no cost to building and manipulating an object graph.
>
> The benefit of the object graph is to keep the object model. However, the
> object model is simply not necessary and has proven not to scale to 10k+
> resources. The Heap/Stack model should scale based on the amount of data
> that you have and would be *extremely* portable to other languages.
>

The agent requires the whole graph for its operation. Since the v1 of this
will only build on top of the existing APIs, I expect the (memory)
situation to get worse before it'll get better. The new API itself doesn't
need a huge object model for its operation. The resources are passed around
as simple arrays and hashes. That could be much more compact than the
current glut of Puppet::Provider instances.

> The biggest down side (for me) is that I manipulate the catalog graph at
> run time for various reasons. There would probably be an easy way to work
> this into the API though since it would just be an array insertion.
>

Yeah, things like file#recurse, or what concat_file does with `generate`
would not be possible with this new API. That is a deliberate decision to
skip a complex fringe feature. I'd love to see what you're doing with it,
to get a better handle of how to re-introduce this in a more pleasant form.
Within the next few years, you'll still be able to just use the puppet 2
T API as-is, if you need to.

> In terms of the validate/munge question, munging can *absolutely* be done
> client side. But do you even want to pass a catalog to the client if you
> have invalid data that might be used by other resources. Also, I do quite a
> bit of checking based on the values of other parameters/properties. If this
> could be maintained reasonably, that would be fine.
>

The hard and generic case of error handling is dynamic errors during
application of the catalog. Puppet will always have to deal with those
gracefully. Are there some validations that could be done earlier than
during the update? Absolutely. How much does it buy us, though? If you have
pointers to cool things you're currently doing, I'd be very interested in
seeing those. No worries about timing. Due to travels, this proposal won't
go anywhere in the next two weeks. And I'd rather have the full picture
anyways.

> I do think that having a global data space would be extremely important to
> making this feasible. There are a couple of tickets on for this as well but
> I don't know the numbers off hand. And, of course, if we use the heap/stack
> model, the data is all in place (but may change based on resource
> processing).
>

Having a proper place to do global transformations on the catalog both
agent and server side would be beneficial to many advanced use-cases. As I
said above, the current way to do so will not go away anytime soon. This
Resource API just won't make it any less painful.

>
> Hopefully this all makes sense.
>

Very much so. I hope the same.

Cheers, David

> Thanks,
>
> Trevor
>
> On Thu, Feb 2, 2017 at 8:42 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
>>
>>
>> On 2 February 2017 at 02:50, Trevor Vaughan <tvaug...@onyxpoint.com>
>> wrote:
>>
>>> Hi David,
>>>
>>> Most of this looks fine (I still need to digest some of it) but I don't
>>> know that I'm a huge fan of no munge or validate functionality. This seems
>>> to fly in the face of a 'fail fast' mentality.
>>>
>>
>> With puppet 4 data types much of the trivial stuff munge and validate do
>> can be handled much easier and consistently than before. Many other checks
>> will never be possible on the server, because they depend on values only
>> available on the agent (credential validity, max tablename length dependent
>> on mysql flavour), or would be error prone duplication of things the target
>> API does check for us (validity of file mode bit combinations, v

Re: [Puppet-dev] Draft for new type and provider API

2017-02-02 Thread David Schmitt

On 2 February 2017 at 02:50, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:

> Hi David,
>
> Most of this looks fine (I still need to digest some of it) but I don't
> know that I'm a huge fan of no munge or validate functionality. This seems
> to fly in the face of a 'fail fast' mentality.
>

With puppet 4 data types much of the trivial stuff munge and validate do
can be handled much easier and consistently than before. Many other checks
will never be possible on the server, because they depend on values only
available on the agent (credential validity, max tablename length dependent
on mysql flavour), or would be error prone duplication of things the target
API does check for us (validity of file mode bit combinations, validity of
AMI references when talking to EC2 instances, etc). There is a bit of stuff
in-between those two (e.g. content specified on a file), which we'd
trade-off for a much simpler server side. Failing on the agent, also means
that independent parts of the catalog can move forward, instead of failing
the whole compilation.


> Also, if everything happens on the client, some of the catalog munging
> that I do on the fly isn't going to work any longer.
>

Those resources will not look anything different than existing types (which
will stay as they are for a considerable while). Since I don't know what
catalog munging you're doing I'm having a hard time following here.

I *do* like the idea of types being pure data but will this bloat the
> catalog even further?
>

The resources in the catalog won't look any different than today. In fact,
the first version will most likely just call Puppet::Type.newtype() under
the hood somewhere.


> I still think that moving toward a heap/stack model would serve the Puppet
> clients best and get past the resource count limitations.
>

Do you have those ideas written up somewhere?


> Fundamentally, I want my clients to do as little work as possible since
> they're meant to be running business processes.
>

Same.


>
> I'll definitely be keeping an eye on this conversation though.
>
> Thanks,
>

Thanks for your time and work you're putting in here.


David


>
> Trevor
>
> On Tue, Jan 31, 2017 at 11:04 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
>> Hi *,
>>
>> The type and provider API has been the bane of my existence since I
>> [started writing native resources](https://github.com/
>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>> Now, finally, we'll do something about it. I'm currently working on
>> designing a nicer API for types and providers. My primary goals are to
>> provide a smooth and simple ruby developer experience for both scripters
>> and coders. Secondary goals were to eliminate server side code, and make
>> puppet 4 data types available. Currently this is completely aspirational
>> (i.e. no real code has been written), but early private feedback was
>> encouraging.
>>
>> To showcase my vision, this [gist](https://gist.github.com
>> /DavidS/430330ae43ba4b51fe34bd27ddbe4bc7) has the [apt_key type](
>> https://github.com/puppetlabs/puppetlabs-apt/blob/
>> master/lib/puppet/type/apt_key.rb) and [provider](https://github.com/
>> puppetlabs/puppetlabs-apt/blob/master/lib/puppet/provider/
>> apt_key/apt_key.rb) ported over to my proposal. The second example there
>> is a more long-term teaser on what would become possible with such an API.
>>
>> The new API, like the existing, has two parts: the implementation that
>> interacts with the actual resources, a.k.a. the provider, and information
>> about what the implementation is all about. Due to the different usage
>> patterns of the two parts, they need to be passed to puppet in two
>> different calls:
>>
>> The `Puppet::SimpleResource.implement()` call receives the
>> `current_state = get()` and `set(current_state, target_state, noop)`
>> methods. `get` returns a list of discovered resources, while `set` takes
>> the target state and enforces those goals on the subject. There is only a
>> single (ruby) object throughout an agent run, that can easily do caching
>> and what ever else is required for a good functioning of the provider. The
>> state descriptions passed around are simple lists of key/value hashes
>> describing resources. This will allow the implementation wide latitude in
>> how to organise itself for simplicity and efficiency.
>>
>> The `Puppet::SimpleResource.define()` call provides a data-only
>> description of the Type. This is all that is needed on the server side to
>> compile a manifest. Thanks to puppet 4 data type checking, this will
>> already be much more strict (with less effort) than possibl

[Puppet-dev] Draft for new type and provider API

2017-01-31 Thread David Schmitt

Hi *,

The type and provider API has been the bane of my existence since I
[started writing native resources](
https://github.com/DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
Now, finally, we'll do something about it. I'm currently working on
designing a nicer API for types and providers. My primary goals are to
provide a smooth and simple ruby developer experience for both scripters
and coders. Secondary goals were to eliminate server side code, and make
puppet 4 data types available. Currently this is completely aspirational
(i.e. no real code has been written), but early private feedback was
encouraging.

To showcase my vision, this [gist](
https://gist.github.com/DavidS/430330ae43ba4b51fe34bd27ddbe4bc7) has the
[apt_key type](
https://github.com/puppetlabs/puppetlabs-apt/blob/master/lib/puppet/type/apt_key.rb)
and [provider](
https://github.com/puppetlabs/puppetlabs-apt/blob/master/lib/puppet/provider/apt_key/apt_key.rb)
ported over to my proposal. The second example there is a more long-term
teaser on what would become possible with such an API.

The new API, like the existing, has two parts: the implementation that
interacts with the actual resources, a.k.a. the provider, and information
about what the implementation is all about. Due to the different usage
patterns of the two parts, they need to be passed to puppet in two
different calls:

The `Puppet::SimpleResource.implement()` call receives the `current_state =
get()` and `set(current_state, target_state, noop)` methods. `get` returns
a list of discovered resources, while `set` takes the target state and
enforces those goals on the subject. There is only a single (ruby) object
throughout an agent run, that can easily do caching and what ever else is
required for a good functioning of the provider. The state descriptions
passed around are simple lists of key/value hashes describing resources.
This will allow the implementation wide latitude in how to organise itself
for simplicity and efficiency.

The `Puppet::SimpleResource.define()` call provides a data-only description
of the Type. This is all that is needed on the server side to compile a
manifest. Thanks to puppet 4 data type checking, this will already be much
more strict (with less effort) than possible with the current APIs, while
providing more automatically readable documentation about the meaning of
the attributes.

Details in no particular order:

* All of this should fit on any unmodified puppet4 installation. It is
completely additive and optional. Currently.

* The Type definition
* It is data-only.
* Refers to puppet data types.
* No code runs on the server.
* This information can be re-used in all tooling around
displaying/working with types (e.g. puppet-strings, console, ENC, etc.).
* autorelations are restricted to unmodified attribute values and
constant values.
* No more `validate` or `munge`! For the edge cases not covered by data
types, runtime checking can happen in the implementation on the agent.
There it can use local system state (e.g. different mysql versions have
different max table length constraints), and it will only fail the part of
the resource tree, that is dependent on this error. There is already ample
precedent for runtime validation, as most remote resources do not try to
replicate the validation their target is already doing anyways.
* It maps 1:1 to the capabilities of PCore, and is similar to the libral
interface description (see [libral#1](
https://github.com/puppetlabs/libral/pull/2)). This ensures future
interoperability between the different parts of the ecosystem.
* Related types can share common attributes by sharing/merging the
attribute hashes.
* `defaults`, `read_only`, and similar data about attributes in the
definition are mostly aesthetic at the current point in time, but will make
for better documentation, and allow more intelligence built on top of this
later.

* The implementation are two simple functions `current_state = get()`, and
`set(current_state, target_state, noop)`.
* `get` on its own is already useful for many things, like puppet
resource.
* `set` receives the current state from `get`. While this is necessary
for proper operation, there is a certain race condition there, if the
system state changes between the calls. This is no different than what
current implementations face, and they are well-equipped to deal with this.
* `set` is called with a list of resources, and can do batching if it is
beneficial. This is not yet supported by the agent.
* the `current_state` and `target_state` values are lists of simple data
structures built up of primitives like strings, numbers, hashes and arrays.
They match the schema defined in the type.
* Calling `r.set(r.get, r.get)` would ensure the current state. This
should run without any changes, proving the idempotency of the
implementation.
* The ruby instance hosting the `get` and `set` functions is only alive
for the duration of an

Re: [Puppet-dev] Re: stdlib validate_* and is_* function deprecation

2016-10-26 Thread David Schmitt

On 25 October 2016 at 18:23, Alex Schultz <aschu...@redhat.com> wrote:

> On Tue, Oct 25, 2016 at 3:13 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
> >
> >
> > On 24 October 2016 at 17:32, <aschu...@redhat.com> wrote:
> >>
> >>
> >>
> >> On Friday, October 21, 2016 at 12:48:44 PM UTC-6, David Schmitt wrote:
> >>>
> >>> Hi,
> >>>
> >>> thank you for voicing your feedback. I can't do my work without it.
> >>>
> >>> On Thursday, October 20, 2016 at 10:49:45 AM UTC-7, asch...@redhat.com
> >>> wrote:
> >>>>
> >>>> So I've recently noticed the deprecation notices for the validate_*
> and
> >>>> is_* functions withing stdlib.  As a consumer of the stdlib who
> currently
> >>>> needs to continue to support puppet 3 and hasn't  moved to puppet 4
> typing
> >>>> for ~40 modules, this is a giant pain.
> >>>
> >>>
> >>> If you are not yet prepared to make the switch, please stay with stdlib
> >>> 4.12.
> >>>
> >>>>
> >>>>  Additionally we do not require (nor leverage) any of the old edge
> cases
> >>>> that are trying to continue to be maintained under the validate_legacy
> >>>> function.
> >>>
> >>>
> >>> validate_legacy and the Compat types are not supposed to continue to
> >>> maintain the mess that were the validate_ functions. They are designed
> to
> >>> help you migrade in an incremental fashin, to leverage the new
> datatypes,
> >>> without forcing your complete installation to switch ot once into the
> new
> >>> world. If you have that kind of control over your modules, or you
> already
> >>> know that you're hitting none of the edge cases, you can of course
> choose to
> >>> do the switch in a single step.
> >>>
> >>>>
> >>>>  Is there a reason we can't just keep these is_* and validate_*
> >>>> functions as is without the deprecation and/or just fix these in a
> newer
> >>>> version of stdlib?
> >>>
> >>>
> >>> You can. Stay with stdlib 4.12.
> >>
> >>
> >>>
> >>>
> >>>>
> >>>>  Is there some additional info as to why this decision was made?
> >>>
> >>>
> >>> We want to start using the "new" puppet 4 features in the supported
> >>> modules to show off the improvements you can gain through them. The
> >>> deprecation and validate_legacy functions are intended to help the
> whole
> >>> ecosystem make this transition without having a flag day where
> everyone has
> >>> to switch.
> >>>
> >>> Using datatypes has a number of advantages over the validate functions:
> >>> * high expressivity: look through the Compat types to see what the
> >>> functions *actually* tested. They accept surprising types and leak
> weird
> >>> edge cases. Using datatypes removes a huge trap, and allows much
> stricter
> >>> specifications.
> >>> * documentability: puppet-strings will surface datatypes in the
> generated
> >>> HTML. validate method calls are invisible.
> >>> * core features: you can leverage the expressivity of datatypes using
> the
> >>> =~ match operator and assert_type everywhere you previously used
> validate
> >>> and is functoins, and the results have a much better chance of meeting
> >>> everyone's expectations
> >>> * extensiiblity: it is very easy to define custom types that match a
> >>> module's domain, while it is very obscure to create your own validate
> >>> functions.
> >>>
> >>
> >>
> >> Shouldn't these types of deprecation occur in a major version like in
> the
> >> 5.x series?
> >
> >
> > Others already have answered this.
> >
> >>
> >>  I get the desire to move forward on these types of changes but the
> >> problem I have is mostly with the forced (and silent) implementation of
> >> these things mid 4.x.
> >
> >
> > This is not mid-4.x. I expect this to be one of the very last 4.x
> releases.
> > There are a few bug fixes currently in flight around IP validation, but I
> > see no reason to delay a stdlib 5.x release for much longer.
> >
> >>
> >>  Swapping out these c

Re: [Puppet-dev] Re: stdlib validate_* and is_* function deprecation

2016-10-25 Thread David Schmitt

On 24 October 2016 at 19:01, Erik Dalén  wrote:

> As an aside we recently got nailed when puppetlabs-ntp became no
>> longer puppet3 compatible on master prior to the new version being
>> released.  As operators and developers, these incompatible transitions
>> really need to be well thought out on their impact.  I can't count the
>> number of times we've been hit when someone decided to change their
>> gem (or ruby) dependencies mid release cycle and it breaks everything
>> even if we don't actually consume any code from that module. Sorry
>> it's a major pet peeve of mine when we have to drop everything and go
>> figure out who's doing breaking changes mid cycle and either pin or
>> find a work around because of backwards incompatibilities.
>>
>
> This sounds like you want a stable environment but yet you are tracking
> master for your dependencies.
> Just wait with upgrading until you have time to do it instead of all the
> time :)
>

I can't emphasize enough how helpful folks running master are. For example
Dominic Cleal, of Foreman fame, found and reported a number of embarrassing
slips on our side over the years before they were released and could impact
the wider community.


Regards, David

-- 
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/CALF7fHYW_MpGfEb9P54iYdPri5DeFM9fz8MjbmZ%3DyaJEQXpGEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: stdlib validate_* and is_* function deprecation

2016-10-25 Thread David Schmitt

On 24 October 2016 at 17:32, <aschu...@redhat.com> wrote:

>
>
> On Friday, October 21, 2016 at 12:48:44 PM UTC-6, David Schmitt wrote:
>>
>> Hi,
>>
>> thank you for voicing your feedback. I can't do my work without it.
>>
>> On Thursday, October 20, 2016 at 10:49:45 AM UTC-7, asch...@redhat.com
>> wrote:
>>>
>>> So I've recently noticed the deprecation notices for the validate_* and
>>> is_* functions withing stdlib.  As a consumer of the stdlib who currently
>>> needs to continue to support puppet 3 and hasn't  moved to puppet 4 typing
>>> for ~40 modules, this is a giant pain.
>>>
>>
>> If you are not yet prepared to make the switch, please stay with stdlib
>> 4.12.
>>
>>
>>>  Additionally we do not require (nor leverage) any of the old edge cases
>>> that are trying to continue to be maintained under the validate_legacy
>>> function.
>>>
>>
>> validate_legacy and the Compat types are not supposed to continue to
>> maintain the mess that were the validate_ functions. They are designed to
>> help you migrade in an incremental fashin, to leverage the new datatypes,
>> without forcing your complete installation to switch ot once into the new
>> world. If you have that kind of control over your modules, or you already
>> know that you're hitting none of the edge cases, you can of course choose
>> to do the switch in a single step.
>>
>>
>>>  Is there a reason we can't just keep these is_* and validate_*
>>> functions as is without the deprecation and/or just fix these in a newer
>>> version of stdlib?
>>>
>>
>> You can. Stay with stdlib 4.12.
>>
>
>
>>
>>
>>>  Is there some additional info as to why this decision was made?
>>>
>>
>> We want to start using the "new" puppet 4 features in the supported
>> modules to show off the improvements you can gain through them. The
>> deprecation and validate_legacy functions are intended to help the whole
>> ecosystem make this transition without having a flag day where everyone has
>> to switch.
>>
>> Using datatypes has a number of advantages over the validate functions:
>> * high expressivity: look through the Compat types to see what the
>> functions *actually* tested. They accept surprising types and leak weird
>> edge cases. Using datatypes removes a huge trap, and allows much stricter
>> specifications.
>> * documentability: puppet-strings will surface datatypes in the generated
>> HTML. validate method calls are invisible.
>> * core features: you can leverage the expressivity of datatypes using the
>> =~ match operator and assert_type everywhere you previously used validate
>> and is functoins, and the results have a much better chance of meeting
>> everyone's expectations
>> * extensiiblity: it is very easy to define custom types that match a
>> module's domain, while it is very obscure to create your own validate
>> functions.
>>
>>
>
> Shouldn't these types of deprecation occur in a major version like in the
> 5.x series?
>

Others already have answered this.


>  I get the desire to move forward on these types of changes but the
> problem I have is mostly with the forced (and silent) implementation of
> these things mid 4.x.
>

This is not mid-4.x. I expect this to be one of the very last 4.x releases.
There are a few bug fixes currently in flight around IP validation, but I
see no reason to delay a stdlib 5.x release for much longer.


>  Swapping out these changes mid 4.x series is not a very good transition
> path for the end user.  The problem I ran into while attempting to address
> these deprecations is that the validate_legacy does not exist until 4.13
> which would force our minimum required stdlib from the current >= 4.0.0 <
> 5.0.0 to >= 4.13.0 < 5.0.0.   I also don't think the validate_legacy works
> under puppet 3. See http://logs.openstack.org/71/
> 389271/1/check/gate-puppet-aodh-puppet-unit-3.8-centos-7/
> e89cc6b/console.html.gz#_2016-10-20_16_36_40_481087
>

To quote the stdlib readme on validate_legacy: "Note: This function relies
on internal APIs from Puppet 4.4.0 (PE 2016.1) onwards, and doesn't work on
earlier versions."

The stdlib module is so ingrained in the community, I just think this
> transition needs better thought around the impact to the end user.  Just
> pinning to <= 4.12.0 is not a quality answer because it just delays the
> problem and can lead to incompatibilities between modules that continue to
> attempt to support both puppet 3 and 4.
>

Only deployments (no

[Puppet-dev] Re: stdlib validate_* and is_* function deprecation

2016-10-21 Thread David Schmitt

Hi,

thank you for voicing your feedback. I can't do my work without it.

On Thursday, October 20, 2016 at 10:49:45 AM UTC-7, asch...@redhat.com 
wrote:
>
> So I've recently noticed the deprecation notices for the validate_* and 
> is_* functions withing stdlib.  As a consumer of the stdlib who currently 
> needs to continue to support puppet 3 and hasn't  moved to puppet 4 typing 
> for ~40 modules, this is a giant pain. 
>

If you are not yet prepared to make the switch, please stay with stdlib 
4.12. 

>  Additionally we do not require (nor leverage) any of the old edge cases 
> that are trying to continue to be maintained under the validate_legacy 
> function.
>

validate_legacy and the Compat types are not supposed to continue to 
maintain the mess that were the validate_ functions. They are designed to 
help you migrade in an incremental fashin, to leverage the new datatypes, 
without forcing your complete installation to switch ot once into the new 
world. If you have that kind of control over your modules, or you already 
know that you're hitting none of the edge cases, you can of course choose 
to do the switch in a single step.

>  Is there a reason we can't just keep these is_* and validate_* functions 
> as is without the deprecation and/or just fix these in a newer version of 
> stdlib?
>

You can. Stay with stdlib 4.12.

>  Is there some additional info as to why this decision was made? 
>

We want to start using the "new" puppet 4 features in the supported modules 
to show off the improvements you can gain through them. The deprecation and 
validate_legacy functions are intended to help the whole ecosystem make 
this transition without having a flag day where everyone has to switch.

Using datatypes has a number of advantages over the validate functions:
* high expressivity: look through the Compat types to see what the 
functions *actually* tested. They accept surprising types and leak weird 
edge cases. Using datatypes removes a huge trap, and allows much stricter 
specifications.
* documentability: puppet-strings will surface datatypes in the generated 
HTML. validate method calls are invisible.
* core features: you can leverage the expressivity of datatypes using the 
=~ match operator and assert_type everywhere you previously used validate 
and is functoins, and the results have a much better chance of meeting 
everyone's expectations
* extensiiblity: it is very easy to define custom types that match a 
module's domain, while it is very obscure to create your own validate 
functions.

> Having to go through our modules and switch out to the validate_legacy 
> functions is an effort we don't have the resources to undertake and the 
> deprecation notices aren't something we can live with as they make it very 
> hard to figure out when something actually breaks.
>

Please see the documentation for the deprecation function in the stdlib 
readme on how to turn on/off deprecations in different situations (via 
puppet configuration on your master, or a environment variable during 
testing). You always have the possibility to stay on stdlib 4.12 until you 
are ready to start your upgrade project. 

> Additionally I'd like to point out that the deprecation notices make it 
> next to impossible to figure out what is deprecated, see 
> http://logs.openstack.org/89/388589/1/gate/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/fc2567b/console.html#_2016-10-19_22_24_59_667975
>
>
Crap. I missed that one. I'm currently at puppetconf, and travelling home 
afterwards, so I won't be able to look into it immediately, but I've 
created https://tickets.puppetlabs.com/browse/MODULES-3993 to track this, 
and will get to it next week. Until then, grepping for 'validate_|is_' is 
probably a good first approximation of everything you'll need to address.

Cheers, David

-- 
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/25f0f2a9-c3e1-49f1-9f7e-1f2e729425c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] rspec-puppet 2.4.0 released

2016-03-24 Thread David Schmitt

Hi *,

I'm very happy to announce a new release of rspec-puppet, the unit test
framework for puppet manifests:

This release now supports testing exported resources in the same way that
normal resources in the catalog are tested. Access them in your examples
using `exported_resources`. See "Testing Exported Resources" in the README
for examples.

### Changed

* This release pulls out much of the version-specific code into separate
classes to reduce complexity and enable easier maintenance going forward.

### Added

* Support colon-separated module_path and environmentpath values.
* Support a threshold for the code coverage test, that can fail the whole
run.
* Ensure a consistent environment for all examples by adding a forced
initialization of puppet before each.

### Credits

Thanks to Adrien Thebo, Arthur Gautier, Brett Gray, and Nicholas Hinds, as
well as all the folks helping out on github for their contributions to this
release.

Cheers, David Schmitt

PS: if you too want to help out, anything you can add to
https://github.com/rodjek/rspec-puppet/tree/gh-pages to improve the online
docs would be of great help!

--
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/CALF7fHYi%2B-vMTSH%2B3Ep08Sto5Kgfdv8RydoTNNOd0wiHL4ErGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] rspec-puppet 2.3.2

2016-01-26 Thread David Schmitt

Hi,

over the weekend there was a situation where the newest puppet versions
(3.8.5 and 4.3.2) would interact badly with the latest version of
rspec-puppet (2.3.0).

Yesterday I uploaded 2.3.1 to fix the issue with 3.8.5 and today there is
2.3.2 to completely fix this across all puppet versions.

If you ran into errors like

NoMethodError: undefined method `resource' for nil:NilClass
>

or

Unsupported data type: 'Symbol' on node ...".
>

please retry with the rspec-puppet 2.3.2.

Apologies for any inconvenience.

David

-- 
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/CALF7fHZmXxdkfUZzxpu-HqGukU-7%2BRf%2BwehUNyobY8wxwgE1oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] rspec-puppet 2.3.0 released

2015-12-15 Thread David Schmitt


Hi *,

I'm very happy to announce a new release of rspec-puppet, the unit test 
framework for puppet manifests:



Rspec-puppet 2.3.0 now supports testing custom types, `:undef` values in 
params, structured facts, and checks resource dependencies recursively.


The settings in `module_path` and `manifest` are now respected 
throughout the code base. The former default for `module_path` 
(`'/etc/puppet/modules'`) was dropped to avoid accidentally poisoning 
the test environment with unrelated code.


To reduce the maintenance overhead of boilerplate code, rspec-puppet now 
provides some of the code that rspec-puppet-init deployed in helper 
files that you can just `require` instead.


This release also reduces memory usage on bigger testsuites drastically 
by reducing the caching of compiled catalogs.


### Changed
- Limit the catalogue cache to 16 entries. Significant memory savings 
and reduced runtime were observed in testing this.

- Prevent Puppet 3's \_timestamp fact from invalidating cache.
- Extracted catalog cache from RSpec::Puppet::Support.
- Updated README to use the rspec 3 syntax, and additional explanations.
- `contain_file(...).with_content(...)` will now only show the diff and 
not the full contents of the file.


### Added
- Custom type testing example group and matcher.
- before/require/subscribe/notify checking now searches recursively 
through all dependencies. `File[a] -> File[b] -> File[c]` is now matched 
by `contain_file('a').that_comes_before('File[c]')`, whereas earlier 
versions would have missed that.
- `let(:params)` now allows `:undef` to pass a literal undef value 
through to the subject.

- Support structured facts with keys as symbols or strings (\#295).
- rspec-puppet-init now creates smaller files, using rspec-puppet 
helpers, instead of pasting code into the module.

- Added a list of related projects to the README.

### Fixed
- Fix #276: `compile.and_raise_error` now correctly considers successful 
compilation an error
- Puppet's `modulepath` can now contain multiple entries and 
rspec-puppet will configure puppet to load code from all of them

- Support running with rspec 2.99 again
- non-class resources are now covered by the coverage code
- Fix #323/MODULES-2374: autorequires checking doesn't abort on 
"undefined method \`[]' for nil:NilClass"

- improved documentation for hiera integration, added example spec
- document the `scope` property

### Credits

Thanks to Adrien Thebo, Alex Harvey, Brian, Dan Bode, Dominic Cleal, 
Javier Palacios, Jeff McCune, Jordan Moldow, Peter van Zetten, Raphaël 
Pinson, Simon Kohlmeyer, and Tristan Colgate for their contributions to 
this release.


  -- David Schmitt

--
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/567057FF.9020309%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Unit testing v4 functions in modules

2015-05-13 Thread David Schmitt

Hi Erik, *!
 

  Is there something equivalent in puppetlabs_spec_helper that works for 
  v4 API functions? 
  
 There is an updated version of puppet-rspec that will help with this. (I 
 heard about this yesterday). Hunner knows more. 


 rspec-puppet 2.1.0 should have all that work. There are a few more 
 patches and bug fixes in the pipeline, but 2.1.0 should already get you far.

 Some examples of rspec-puppet only function testing can be found in the 
 upcoming refresh of stdlib's function specs, currently in my WIP branch 
 here:


 https://github.com/DavidS/puppetlabs-stdlib/commits/modules-1882-rspec-puppet-migration



 It seems like you only have one function using the v4 API (type_of), and 
 the unit test for that is only run on Puppet 4.0, but the travis matrix 
 doesn't specify puppet 4.0 at all. So the test for that doesn't run. Does 
 it work if you try it locally with Puppet 4.0?


 To demonstrate the issue I created a minimal test module (
 https://github.com/dalen/puppet-v4functiontest), and it still doesn't 
 work with rspec-puppet 2.1.0: 
 https://travis-ci.org/dalen/puppet-v4functiontest/builds/60517933

 Do you have any idea what is wrong with that code?


Yeah, I've now finally found out what is wrong with this. Puppet4 requires 
the `environment path` setting to find the code. spec-puppet's own test 
suite sets this, but it does not setup projects with this setting. I've 
submitted a PR to fix this. module projects will have to update this 
manually.

rspec-puppet PR: https://github.com/rodjek/rspec-puppet/pull/288
fixed code in your test module I've used for 
debugging: 
https://github.com/DavidS/puppet-v4functiontest/tree/update-rspec-infra

Cheers, David

-- 
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/e2dd083a-3171-40dc-9510-cde40ba938a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Unit testing v4 functions in modules

2015-05-11 Thread David Schmitt



On Friday, May 8, 2015 at 12:19:51 PM UTC+1, Erik Dalén wrote:



 On Thu, 7 May 2015 at 13:16 David Schmitt david@puppetlabs.com 
 javascript: wrote:

 Hi,


 On Tuesday, April 28, 2015 at 3:54:09 PM UTC+1, henrik lindberg wrote:

 On 2015-28-04 15:16, Erik Dalén wrote: 
  Do any of you have any tips in regards to unit testing function using 
  the v4 API in modules? 
  
  I would like to do something like this: 
  
 https://github.com/puppetlabs/puppet/blob/master/spec/unit/functions/scanf_spec.rb
  
  
  But PuppetSpec::Compiler  Matchers::Resource are in the spec/lib 
  directory of puppet which I can't depend on from a module AFAIK. 
  
  Is there something equivalent in puppetlabs_spec_helper that works for 
  v4 API functions? 
  
 There is an updated version of puppet-rspec that will help with this. (I 
 heard about this yesterday). Hunner knows more. 


 rspec-puppet 2.1.0 should have all that work. There are a few more 
 patches and bug fixes in the pipeline, but 2.1.0 should already get you far.

 Some examples of rspec-puppet only function testing can be found in the 
 upcoming refresh of stdlib's function specs, currently in my WIP branch 
 here:


 https://github.com/DavidS/puppetlabs-stdlib/commits/modules-1882-rspec-puppet-migration



 It seems like you only have one function using the v4 API (type_of), and 
 the unit test for that is only run on Puppet 4.0, but the travis matrix 
 doesn't specify puppet 4.0 at all. So the test for that doesn't run. Does 
 it work if you try it locally with Puppet 4.0?


 To demonstrate the issue I created a minimal test module (
 https://github.com/dalen/puppet-v4functiontest), and it still doesn't 
 work with rspec-puppet 2.1.0: 
 https://travis-ci.org/dalen/puppet-v4functiontest/builds/60517933

 Do you have any idea what is wrong with that code?


No, but I've been able to reproduce this now locally and I'll have a look 
at what's going on there.


Regards, David 

-- 
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/9d3940a6-60a2-4c6a-ab0d-1b9af31cb955%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: Unit testing v4 functions in modules

2015-05-07 Thread David Schmitt

Hi,

On Tuesday, April 28, 2015 at 3:54:09 PM UTC+1, henrik lindberg wrote:

 On 2015-28-04 15:16, Erik Dalén wrote: 
  Do any of you have any tips in regards to unit testing function using 
  the v4 API in modules? 
  
  I would like to do something like this: 
  
 https://github.com/puppetlabs/puppet/blob/master/spec/unit/functions/scanf_spec.rb
  
  
  But PuppetSpec::Compiler  Matchers::Resource are in the spec/lib 
  directory of puppet which I can't depend on from a module AFAIK. 
  
  Is there something equivalent in puppetlabs_spec_helper that works for 
  v4 API functions? 
  
 There is an updated version of puppet-rspec that will help with this. (I 
 heard about this yesterday). Hunner knows more. 


rspec-puppet 2.1.0 should have all that work. There are a few more patches 
and bug fixes in the pipeline, but 2.1.0 should already get you far.

Some examples of rspec-puppet only function testing can be found in the 
upcoming refresh of stdlib's function specs, currently in my WIP branch 
here:

https://github.com/DavidS/puppetlabs-stdlib/commits/modules-1882-rspec-puppet-migration




Regards, David
 

-- 
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/0244e11a-530f-4e84-ae50-34d4be7c593a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Using puppet for the configuration of a custom appliance

2015-04-07 Thread David Schmitt


On 2015-04-06 20:54, varun umesh wrote:

I am planning to use puppet for the configuration of a custom network
appliance. My main problem is i am unable to install puppet on the
appliance, as it is not supported. I have access to the rest api's
exposed by the appliance. So can i use puppet to make the rest api calls
and try to do the configurations as and when a parameter changes? Could
anybody suggest me a good way to handle this problem?

Thanks!


Hi,

you want to look into the puppet device support. Start at the initial 
blog post here:



https://puppetlabs.com/blog/puppet-network-device-management


Not much has changed since then. You can find example code of working 
device drivers on github.


Have fun, David
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/55245427.7010705%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Default environment_timeout preference

2015-03-05 Thread David Schmitt


This.

On 2015-03-06 03:42, Adrien Thebo wrote:

To me, following the principle of least astonishment indicates that
caching be disabled by default; it'll work correctly for new users and
has no hidden gotchas. When people want to do performance tuning they're
probably fairly sophisticated users and can deal with weird cache
invalidation issues; since they're opting into this feature they should
be prepared to deal with the ramifications.



Regards, David

--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/54F93BC9.3050200%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

2015-02-26 Thread David Schmitt

On 2015-02-26 20:31, John Bollinger wrote:

On Wednesday, February 25, 2015 at 6:06:33 PM UTC-6, Trevor Vaughan
wrote:

I think I filed a bug about this a while back.

+1 for autorequiring targets

+1 from me too. Slightly conditional on the discussion below.

I'm inclined to disagree. Autorequiring should be reserved for cases
where the requirement is inherent in the resource's nature. Files'
dependencies on their parent directories are a good example (except
when ensuring 'absent'): when a file and its directory are both under
management, you cannot be confident of managing the file properly if
you do not first manage its directory.

Symbolic links do _not_ have the same kind of relationship with their
targets. A link can be managed entirely independently of its target,
therefore Puppet should not automatically demand a particular order.
As a general rule, it is important for resource types to model their
corresponding physical resources as cleanly as possible, lest
unintended consequences arise. In this particular case, autorequiring
link targets can create dependency cycles in cases that would
otherwise be perfectly good.

Examples please? Everything I can currently think of right now (and
it's night time here, so please be gentle) would create invalid
filesystem layouts if the symlink points to one of it's own
subdirectories. Or, maybe a scenario where /srv/app is owned by
app_user, whose home directory is below /srv/app/something. But that
would be a cycle /srv/app - owner - home - /srv/app without any
symlink.

I observe, too, that in the example presented, the convenience
afforded by the proposed autorequirement is a function of the *use*
of

the resource, not inherent in the resource itself. Puppet cannot know
that, or be expected to account for it. It is the manifest author who
should be expected to take responsibility for modeling such
site-specific requirements.

I would argue, that the primary *use* of a symlink is to point to
something. Even in the obscure case of pointing to something that is
managed as ensure=absent, I would posit that the intended state of the
symlink is only reached after its target's managed state is reached too.

Regards, David

John

https://groups.google.com/d/msgid/puppet-dev/1aecc279-4620-4a36-bfb4-8f38c9ea3479%40googlegroups.com
[2].
For more options, visit https://groups.google.com/d/optout [3].

Links:
--
[1] mailto:puppet-dev+unsubscr...@googlegroups.com
[2]

https://groups.google.com/d/msgid/puppet-dev/1aecc279-4620-4a36-bfb4-8f38c9ea3479%40googlegroups.com?utm_medium=emailutm_source=footer
[3] https://groups.google.com/d/optout

--
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/64316026360e35824b8c5dda368b57ed%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Dealing with transitional states in Puppet

2014-12-20 Thread David Schmitt


On 2014-12-19 22:14, Reid Vandewiele wrote:

transition { 'stop myapp service':
   resource   = Service['myapp'],
   attributes = { ensure = stopped },
   prior_to   = File['/etc/myapp/myapp.cfg'],
}

file { '/etc/myapp/myapp.cfg':
   ensure  = file,
   content = 'mycontent',
   notify  = Service['myapp'],
}

service { 'myapp':
   ensure = running,
   enable = true,
}

We implemented a prototype and published it at
https://forge.puppetlabs.com/puppetlabs/transition. It's 0.1.0 code,
basically first cut, just enough to build out and test the idea, but not
all the rough edges are sanded off. There's more detail in the readme on
the Forge page.We implemented a prototype and published it at
https://forge.puppetlabs.com/puppetlabs/transition. It's 0.1.0 code,
basically first cut, just enough to build out and test the idea, but not
all the rough edges are sanded off. There's more detail in the readme on
the Forge page.

Does this pattern or capability make sense in the general context of
Puppet? Is this a decent interim solution for something better currently
under development? What do people think of this?



More flexible state management is something that is very much on my mind 
in recent times. As other products (like ansible) solve this much better.


Given the restricted malleability of the manifest language, I think your 
implementation is already quite advanced and will solve problems.



Regards, David




--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5495B94C.805%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet 4 delivery and upgrades

2014-12-14 Thread David Schmitt

Hi,

The usual argument at this point in the discussion is that AIO packages
of any vendor will - by definition - have worse security support than
the system versions.

People who have to certify/verify/validate/audit all binaries that are
running on a given system will have additional high costs from bundled
components that may render using those packages infeasible.

Adding more binaries to a system will mean that they will require
additional non-dedup-able hardware resources.

Independently of those technical arguments, freeing puppetlabs from the
ruby hell will be read by free software proponents(sic!) as
unwillingness to support the diversity of the free software ecosystem.
See also http://islinuxaboutchoice.com/ and so on. My own opinion is
split between the economical realities of vendors and the fact that
everything outside Debian main (+ backports) is not *Debian*.

Regards, David

On 2014-12-12 21:39, Byron Miller wrote:

I don't see these negatives at all. I think having puppet decoupled is a
good thing - for reliability, management and freeing us from ruby
hell. I can't see an AIO package altering the native behavior of the
OS or system rubbies either..

Since it is OSS as well, is there a reason you wouldn't be able to pull
down the git repo and update ruby according to your own needs? my
assumption is that its a LOT easier to upgrade puppet ruby if it is
indeed decoupled from system ruby or ruby used by apps on the platform
your trying to manage.

-byron

On Thursday, December 11, 2014 3:53:15 PM UTC-6, John Bollinger wrote:

On Thursday, December 11, 2014 3:34:17 PM UTC-6, John Bollinger wrote:

If I cannot install Puppet into a Ruby installation of my choice
(of sufficiently recent version) and have it work correctly, or
if its installation alters the behavior of other software
relying on that Ruby, then I do not foresee updating until I or
someone else can fix those problems. I am unlikely to be able
to devote any effort to such an endeavor any time soon, so my
adoption of the new version would be forestalled indefinitely.

Similarly, as long as Puppet is unable to share general-purpose
third-party components, such as Ruby modules or a Java runtime, with
other subsystems, I do not anticipate updating.

Although I am disappointed that PL intends to offer only AIO
packages, that decision will be only an inconvenience for me as long
as the software does not inherently /depend/ on AIO structure and
layout. You may make suggestions, but you may not make system
configuration decisions for me.

John

--
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
mailto:puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/052267c9-5504-4587-84d5-a2f5442065e5%40googlegroups.com
https://groups.google.com/d/msgid/puppet-dev/052267c9-5504-4587-84d5-a2f5442065e5%40googlegroups.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.

--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/548DFC3B.2070604%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Handling Interdependent Files in a typeprovider

2014-12-09 Thread David Schmitt


On 2014-12-05 10:28, Igor Galić wrote:

Fellow Humans!

i would like solicit your expert knowledge in designing a type  provider for
Apache Traffic Server's 
[storage.config](http://trafficserver.readthedocs.org/en/latest/reference/configuration/storage.config.en.html)

The basic outline of my general idea, which i implemented with finch's
Filemapper, and finch's help(!) can be found here:

type: 
https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/type/trafficserver_storage.rb
provider baseclass: 
https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/provider/trafficserver_storage.rb
 (literally, a class, this was finch's idea ;)
provider for linux: 
https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/provider/trafficserver_storage/udev_storage.rb

(ignore it for now;)

now the problem that i'm trying to solve is as follows:

storage.config *drives* the configuration process: when it changes, *something*
on the system changes too. this could either mean a

* directory needs to be created and chowned to the correct user
* udev|devfs entry needs to be made and udev needs to be reloaded

the first case is easy and platform independent (i.e.: it works on all Unix
platforms equally, and traffic server only runs on Unix, so it's fine ;)

the second case however is more problematic as it means we need to keep two
syntactically distinct files in sync. it also means that we need to verify, and
possibly recreate that secondary file if *nothing* in the primary file at all
has changed.

now, from what i gather, a provider cannot be split on a line-by line basis,
but maybe i'm wrong there. in my design above i integrated the directory case -
as an if statement - into the base provider. Considering all the things i've
learned about refactoring in the past three months, this strikes me now as a
profoundly bad move ;)

as for the second case, at least with filemapper, this is really hard to do:
the udev/devfs files would have to be handled in ruby, rather than in
filemapper, if i use inheritance.

and so i'm stuck, and would like some advise on how to handle this properly.


Both parts of the problem strike me as being caused by your try to chain 
a secondary configuration off of the storage.config handling. This might 
be the most straightforward/logical map of the trafficserver's logic, 
but it does not really reflect the reality of puppet managing it. You 
seem to have already considered factoring the problem into a puppet 
define that manages the storage.config and the directory in parallel 
(judging from the comment in [¹]) but I do not quite follow your 
reasoning and would think that a separate type to handle the actual 
config file and a define to actually configure a tserver::directory, 
tserver::raw_device, etc. would allow you to have proper parameters 
depending on the configured cache location type and surprisingly also 
provide you with a high degree of safety.



define trafficserver::device($id = undef, $volume = undef) {
trafficserver_storage { $name: id = $id, volume = $volume; }
udev::access_rule { $name: user = $trafficserver::user, ... }
}

define trafficserver::directory($size, $id = undef, $volume = undef) {
validate_path($name)
validate_size($size)
trafficserver_storage { $name: id = $id, volume = $volume, size = 
$size; }
file { $name: ensure = directory, force = false, owner = 
$trafficserver::user, ... }
}



Splitting it like this would also create independently usable artifacts 
(trafficserver_storage parser, udev::access_rule) that allow people to 
build their own stuff on top without having to workaround built-in 
assumptions. (trafficserver::nbd_mirror anyone?)



Regards, David

[¹]https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/provider/trafficserver_storage.rb#L102

--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/54871238.10006%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?

2014-12-05 Thread David Schmitt


On 2014-12-03 22:42, Rob Reynolds wrote:

 For the
other items, please create tickets (feel free to point back to this
discussion) and we can get them prioritized. Thanks!


You mean, like https://tickets.puppetlabs.com/browse/PUP-1298 back from 
2013. Or http://projects.puppetlabs.com/issues/7241 from 2011?



Regards, David
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5481AE10.6090906%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?

2014-11-27 Thread David Schmitt


On 2014-11-26 19:02, Rob Reynolds wrote:

Making a switch to non-authoritative would be in the realm of
possibility for Puppet 4 given the short timeline. I think the
group_membership resource type could be something that could be done at
any time, and then the other properties deprecated and removed by Puppet
5 or 6. Given that the group_membership is a bit larger and would need
more time for deprecations, I'd like to bring this back to just the
non-authoritative.

Would it be a beneficial switch to move to non-authoritative?


Given that the groupadd provider is the only provider relevant to the 
majority of Linux systems, and it is INCAPABLE of managing group 
members, I'm slightly amused by that question. Therefore I follow John's 
point of it being a net win based on principles as it cannot influence 
any of my systems.



Regards, David

--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5476DB7B.6080705%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?

2014-11-27 Thread David Schmitt

Awesome, thanks! That would have saved me a quite awkward moment at a
client. :-)

Regards, David

On 2014-11-27 16:08, Trevor Vaughan wrote:

There's a patch for that.

https://github.com/onyxpoint/puppet-gpasswd/blob/master/lib/puppet/provider/group/gpasswd.rb

It was not included due to not wanting to increase the code in the core.

Trevor

On Thu, Nov 27, 2014 at 3:06 AM, David Schmitt da...@dasz.at
mailto:da...@dasz.at wrote:

On 2014-11-26 19:02, Rob Reynolds wrote:

Making a switch to non-authoritative would be in the realm of
possibility for Puppet 4 given the short timeline. I think the
group_membership resource type could be something that could be
done at
any time, and then the other properties deprecated and removed
by Puppet
5 or 6. Given that the group_membership is a bit larger and
would need
more time for deprecations, I'd like to bring this back to just the
non-authoritative.

Would it be a beneficial switch to move to non-authoritative?

Given that the groupadd provider is the only provider relevant to
the majority of Linux systems, and it is INCAPABLE of managing group
members, I'm slightly amused by that question. Therefore I follow
John's point of it being a net win based on principles as it cannot
influence any of my systems.

Regards, David

--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+__DavidSchmitt
https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/__davidschmitt
http://at.linkedin.com/in/davidschmitt

--
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+unsubscribe@__googlegroups.com
mailto:puppet-dev%2bunsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/__msgid/puppet-dev/5476DB7B.__6080705%40dasz.at
https://groups.google.com/d/msgid/puppet-dev/5476DB7B.6080705%40dasz.at.
For more options, visit https://groups.google.com/d/__optout
https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com mailto:tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

--
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
mailto:puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVqbHDhumFt5_eQLtFY%2BHocDKOHqcE8Mo_9zk%2BQmazy8w%40mail.gmail.com
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVqbHDhumFt5_eQLtFY%2BHocDKOHqcE8Mo_9zk%2BQmazy8w%40mail.gmail.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.

--
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/54774146.3070401%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Using metadata.json dependencies in the master

2014-11-26 Thread David Schmitt


Hi,

I've run into the problem of conflicting dependencies several times: for 
example, quite a few public modules use different apache module 
implementations. While it is often to fix those modules locally to use 
the preferred version, it is cumbersome and error prone.


I was wondering whether it would be possible to have the modules 
installed not to $modulepath/$modulename, but to 
$modulepath/$author-$modulename and have the master pick up the right 
classes/defines, depending on the information in metadata.json, 
similarly to how bundler sets up gems.


Of course, that doesn't fix configurations where multiple different 
versions of the same module name are required on the same node, but 
that's a different quality of problem, that can be quite easily fixed by 
using separate nodes, without modifying the modules themselves.


Is this something that would be possible/feasible?

Regards, David
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5476D9A2.7020107%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Setting log levels in puppet.conf

2014-11-05 Thread David Schmitt

True. Making --test a must be at least info, instead of exactly 
equal makes sense and doesn't violate my statement.


D.

On 2014-11-05 09:58, Michael Smith wrote:

I agree, though I like changing the definition of --test to be at least --info 
instead of exactly (solution 1). It makes the behavior more useful.

Sent from my iPad


On Nov 4, 2014, at 10:53 PM, David Schmitt da...@dasz.at wrote:


On 2014-11-04 22:46, Josh Cooper wrote:
Stefan Goethals added the ability to specify puppet's log_level in
puppet.conf[1] and it will be available in Puppet 4.0. This was
originally redmine ticket #4761, so thank you Stefan for resolving that!

I did run into one surprise and wanted to get feedback. If you specify
log_level=debug in puppet.conf, and run with `puppet agent --verbose`
(or more commonly `puppet agent --test`, which implies `--verbose` and a
bunch of other settings), then the agent's log_level will be reset back
down to the info level, and you won't get any debug output.

To see debug output, you have to execute `puppet agent --test --debug`
or specify a lot of the things `--test` implies, but leave out
`--verbose`, e.g `puppet agent --no-daemonize --onetime`

The problem originates in Puppet::Application#set_log_level

 if options[:debug]
   Puppet::Util::Log.level = :debug
 elsif options[:verbose]
   Puppet::Util::Log.level = :info
 end

The code assumes that if debug is not specified on the command line, but
verbose is, then the log level must be info. If the log level is set to
debug in puppet.conf, then this will actually downgrade the logging
level to info.

We could fix this a few different ways.

1. If --verbose (or --test) is specified, then ensure the log_level is
*at least* at the info level
2. Change --test to imply --debug instead of --verbose
3. Something else?

Josh

[1] https://tickets.puppetlabs.com/browse/PUP-2998


Commandline options should always trump config file settings for reduced 
surprise factor.


Regards, David

--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5459C983.1060605%40dasz.at.
For more options, visit https://groups.google.com/d/optout.





--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/545A59F5.4070906%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Setting log levels in puppet.conf

2014-11-04 Thread David Schmitt


On 2014-11-04 22:46, Josh Cooper wrote:

Stefan Goethals added the ability to specify puppet's log_level in
puppet.conf[1] and it will be available in Puppet 4.0. This was
originally redmine ticket #4761, so thank you Stefan for resolving that!

I did run into one surprise and wanted to get feedback. If you specify
log_level=debug in puppet.conf, and run with `puppet agent --verbose`
(or more commonly `puppet agent --test`, which implies `--verbose` and a
bunch of other settings), then the agent's log_level will be reset back
down to the info level, and you won't get any debug output.

To see debug output, you have to execute `puppet agent --test --debug`
or specify a lot of the things `--test` implies, but leave out
`--verbose`, e.g `puppet agent --no-daemonize --onetime`

The problem originates in Puppet::Application#set_log_level

 if options[:debug]
   Puppet::Util::Log.level = :debug
 elsif options[:verbose]
   Puppet::Util::Log.level = :info
 end

The code assumes that if debug is not specified on the command line, but
verbose is, then the log level must be info. If the log level is set to
debug in puppet.conf, then this will actually downgrade the logging
level to info.

We could fix this a few different ways.

1. If --verbose (or --test) is specified, then ensure the log_level is
*at least* at the info level
2. Change --test to imply --debug instead of --verbose
3. Something else?

Josh

[1] https://tickets.puppetlabs.com/browse/PUP-2998


Commandline options should always trump config file settings for reduced 
surprise factor.



Regards, David

--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5459C983.1060605%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] The string to number torture never stops

2014-11-01 Thread David Schmitt


On 2014-11-01 01:22, Henrik Lindberg wrote:

Somehow fitting, Halloween and all... for what I want to bring up.


Indeed. Cross type interactions are the worst.


Yet again someone was bit by the automatic String to Numeric conversion
that is in Puppet (and also in --parser future).

The particular thing this time was
https://tickets.puppetlabs.com/browse/PUP-3602 that caused certain md5
fingerprints to look like floating point values of value 0 (they all
started with 0e but had different digits after the e, and since 0 * 10
^something is always 0 the two different md5 fingerprints were reported
to being equal.


Wow.


The best cure is naturally to never do String to numeric conversion. And
we wonder what people feel about that. Should we go for this in Puppet
4.0.0 (and have a 3.7.4 release as the last of the 3x series where this
behavior is implemented when using --parser future).


thirce yes!


The requirement to compare strings and numerals can also be implemented 
by converting the numeral to a string (using a canoical non-locale 
dependent format). This produces a much safer route, as creating a 
string has less degrees of freedom.



There has also been a number of other suggestions how to fix this, that
are less appealing, and for the sake of not having to waste anyone's
time, here they are, with the reasons why they are not so appealing.

* Only convert if LHS is a Number. This makes the order of the
comparison matter and then ($x == $y) != ($y == $x) which is really bad.

* Add === operator to compare both type and value. This is a slippery
slope since we probably want Integer and Float to compare equal - say
0.0 and 0. It adds yet another operator, and we have to decide what
case, selector and in should use since there is no way to specify if one
or the other should be used.


I'd not call that a slope, that's a cliff. See how PHP and javascript 
struggle with this.



Instead, since we already have sprintf for value to string conversion,
and there is a scanf in Ruby which does the conversion the other way, we
can simply add that function to core puppet for value conversion.

We could also add to_number(s), or to_number(s, format_string).
When doing that though, we risk ending up with a plethora of to_xxx
functions, and we could instead offer one more universal
convert_to(Type, value, options) function e.g.


Regardless of how you implement it, a good conversion function must be 
*strict*. things like 3 Apples (or md5 hashes) cannot safely be 
converted into a number, even if some functions valiantly try.




# best effort, or fail
convert_to(Number, value)

# only if it is an integer, or fail
convert_to(Integer, value, {base = 10})

# convert integer to hex string with some extra text (the sprintf way)
convert_to(String, value, {format = Hex %x})

# convert to array of string (give full control over all
# nested conversions.
#
convert_to(Array[String], value, {
   Integer = { format = 0x%x },
   Float   = { format = %#.4G }})

# etc.

So - Boldly break all the (s)t(r)hings?

- henrik




--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5454B78C.5030202%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Auto*

2014-09-24 Thread David Schmitt


On 2014-09-23 22:09, Felix Frank wrote:

On 09/23/2014 09:19 PM, David Schmitt wrote:


Are you sure we want that? Are you sure *you* do? ;-)


We only supply the guns, people kill people.


Then this is us I guess:

https://soundcloud.com/nightvaleradio/25-one-year-later-1#t=08:55

;-)



Indeed ;-)


Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/54226175.4070909%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Auto*

2014-09-23 Thread David Schmitt


On 2014-09-23 21:03, Felix Frank wrote:

On 09/23/2014 08:47 PM, Trevor Vaughan wrote:

Sitting here at PuppetConf and I just added a PR for the ability to
use autorequire, autobefore, autonotify, and autosubscribe to
custom/native types.

https://tickets.puppetlabs.com/browse/PUP-3331

It worked during my testing, but anyone that's willing to externally
verify would be most appreciated.

Thanks, and hope everyone is having a good conference!

Trevor


Autonotify...?

I like your way of thinking big and building good things but...this
makes me shudder a bit.

Are you sure we want that? Are you sure *you* do? ;-)


We only supply the guns, people kill people.



Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/5421C7D6.8090201%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Facter version guarantees

2014-08-30 Thread David Schmitt


Hi,

I really like the points Eric, Wil and Henrik have brought up. Here're 
some more from me.


On 2014-08-29 23:11, Kylo Ginsberg wrote:

[Splitting this out of the original thread which was the Facter 2.2.0
announcement.]

On Thu, Aug 28, 2014 at 2:58 AM, David Schmitt da...@dasz.at
mailto:da...@dasz.at wrote:

On 2014-08-28 00:51, Kylo Ginsberg wrote:

But going forward there's a question about how to handle changes
to fact
*values*. One proposal is that we identify (and of course test
against)
some essential facts that we care a lot about (such as
'lsbmajdistrelease) and set some rules, like:

(a) we do not change those in x.y.Z releases
(b) we highlight it when they DO change in x.Y or X releases



Strict semver would suggest that (major) changes to values be marked
with an increment in the major version.


There are a couple really good issues here, and I'm torn on the answers:

1) While semver clearly applies to the Facter *API*, I'm not sure if it
provides guidance on Facter *values*. Yes, on the one hand, I could
argue that the values are part of the Facter contract, but that seems
like a contortion of API. I incline toward treating semver as API-only.


That's only semantic BS. The primary consumer of facter is puppet code 
writers. If the meaning of return values of something like sprintf would 
change, all hell would break loose. Why should it be different for the 
return value of $operatingsystem ?


Semver's exclusion of UIs is due to the fact that users are much, *much* 
more flexible to react to changes than deployed code.



2) More importantly, a strict reading of semver as applied to facts
would tie our hands (or force more rapid majors). E.g. I add fact 'foo'
in 3.0, and it turns out to work great on RHEL but is incoherent on,
say, Windows. But it's now out in the wild, so if I'm completely strict
about changes we have to leave it be until 4.0, although that may mean
that more and more Windows users painfully write manifests around the
3.0 behavior.

It's roughly (hand wave) that sort of consideration that led to the idea
floated above of define some major facts (and platforms) where we make
guarantees.

To tie (1) and (2) together, there's a case to be made for separating
Facter's API guarantees from its fact value guarantees, and perhaps even
to tiering the latter. The exact details are up for discussion of course.


That is totally legitimate and starting a separate semver stream for the 
values just underlines that they too are API (if also perhaps a 
different set).


Something that can be done to ease the semver pressure is start 
collecting recipes to avoid disaster when the inevitable glitch happens.
For example, if a certain fact produces garbage on a platform and fixing 
it would require wide-spread changes, one could add a $FACT_ex fact that 
returns the fixed values in a minor version and fold that change into 
the normal fact on the next major bump. Or start a versioned facts hash 
so that the consumer can choose which version to access. I suggest the 
latter because even if the fact-value-semver is decoupled from facter's 
semver, manifests will have to deal with a broad range of deployed 
versions and having to keep all permutations and bugs straight won't be 
easier, just because it now has a version.




Regards, David

--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/540186DB.8010406%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: [Puppet Users] Re: Announce: Facter 2.2.0

2014-08-28 Thread David Schmitt


On 2014-08-28 00:51, Kylo Ginsberg wrote:

But going forward there's a question about how to handle changes to fact
*values*. One proposal is that we identify (and of course test against)
some essential facts that we care a lot about (such as
'lsbmajdistrelease) and set some rules, like:

(a) we do not change those in x.y.Z releases
(b) we highlight it when they DO change in x.Y or X releases



Strict semver would suggest that (major) changes to values be marked 
with an increment in the major version.


If it is properly documented though, manifests can conditionalize any 
changes on $::facterversion. Annoying, but doable if properly documented.



Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/53FEFD2C.9020603%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Noob question structure and calling a class

2014-08-28 Thread David Schmitt


On 2014-08-28 10:02, Felix Frank wrote:

Hi,

this question would be more appropriate on the puppet-users list.

I suspect that the cause for your issue got lost during anonymization.
Does the module/subdirectory/class name contain some unusual character
outside the [a-zA-Z0-9_] range?


Also, does file_c.pp contain a class module_a::folder_b::file_c ?


Regards, David


On 08/28/2014 01:25 AM, Abel Paz wrote:

in using eclipse with geppetto, i am running into an error

I have a file structure like this..

module_a
   |
   |
   manifests
   |
   |
   folder_b
  |
  |
  file_c.pp
  |
  |
  file_d.pp

#/module_a/manifests/folder_b/file_d.pp
 class{'module_a::folder_b::file_c': parama = 'something'}
 class{'module_a::folder_b::file_c': parama = 'somethingelse'}
 class{'module_a::folder_b::file_c': parama = 'somethingelsemore'}

I keep getting the following error:
unknown class: 'module_a::folder_b::file_c'





--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/53FEFD6A.5010003%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Syntax of resource expressions (was: Decision: Near future of resource expressions)

2014-08-06 Thread David Schmitt


Hi,

thanks for keeping the ball rolling!

On 2014-08-06 02:51, Andy Parker wrote:

I'm pulling this discussion out into a new thread so that we can become
more focussed. I'm also going to start a thread about one other topic
that has been brought to my attention so that a decision can be reached.

In this thread I'd like to get to a decision about two aspects of
resource expressions:

   1. Whether to allow expressions in the type position ($a { hi: })


 The use case for number 1 is to provide determining the exact type of a
 resource at runtime. An example would be a module that had different
 implementations for debian vs redhat. It can then use parts of its self
 like so:

apache::install::$osfamily { 'something': }

 Note: I'm not promoting this or saying that this kind of construction
 should appear everywhere, but it is a feature that isn't available in
 the language at the moment.


What Trevor said: highly prone to misuse, but for the use case given, +1 
as a shortcut to create_resources.


Note: we talked about $ a having various types, but I think this 
question only is about values that are Strings or Types, which I think 
is a very sensible restriction to avoid the complexities and abuses 
beyond the specified use case.



   2. Whether to allow using hashes as resources parameters
   3. If we allow hashes as resource parameters, what token introduces
it (no introducing token isn't an option because of implementation
constraints).


I really like Reid's suggestion to use a proper attribute name instead 
of an asterisk.



The use case for number 2 is determining dynamically what parameters
need to be included. In fact I saw a question just recently where
someone tried to do (something like):

   service { 'apache':
 if $control_service {
   ensure = running
 }
 enabled = true
   }

That could be done instead as:

   $params = if $control_service {
 { ensure = running }
} else {
  { }
}
service { 'apache':
   * = $params;
 default:
   enabled = true
 }


This code gives me the hives. As I've replied in that thread, my usual 
way to write this is


  service { 'apache':
enabled = true
  }

  if $control_service {
Service['apache'] { ensure = running }
  }

If I were forced to use hashes, I think I'd write something along these 
lines:


  $service_params = {
enabled = true
  }
  if $control_service {
$service_params['ensure'] = 'running'
  }
  create_resource('service', $service_params)

Re-reading that, it could be even argued, that it flows better because 
the create_resource is at the end, and all relevant values are collected 
before, while my way adds values after the resource definition. Also the 
hash version doesn't duplicate the resource title. I'm beginning to like 
it even better.


To show Reid's proposal:

  $service_params = $control_service ? {
true = { $ensure = 'running' }
false = {}
  }

  service { 'apache':
enable = true,
defaults = $service_params;
  }

also very concise and readable to me.



A second use case is to provide a way of allowing local defaults to be
reused across multiple resources. And a third one was presented by Erik.

Are these use cases invalid or not needed? If not, how should they be
solved? There is create_resources. Is that really a good solution? I ask
that in all seriousness given that the only purpose of the puppet
language is to construct catalogs of resources to manage configurations
and the current syntax for those fundamental elements are so inflexible
that we had to add a function to leave the language for slightly more
advanced resource creation scenarios.

Puppet Labs has a UX department that is at the ready to perform any user
testing or usability analysis that anyone thinks might be valuable to
answer these questions. If we can work out what kinds of questions there
are we can definitely get some study done.


I do like both the defaults: title keyword and Reid's 
'(attribute|param)_(override|defaults|hash)' metaparam instead of the 
splat operator proposals. Both are shorthands for hash manipulation and 
a create_resource call. In the most general sense, the whole Puppet DSL 
is a shorthand for hash manipulation and create_resource calls. So for 
me the questions is, are those shorthands understandable and valuable, 
that is, more readable/modifyable/writeable than a hash+create_resource. 
Like Trevor has suggested, we all might not be the best suited to reason 
about this ;-)



Regards, David



On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg
henrik.lindb...@cloudsmith.com mailto:henrik.lindb...@cloudsmith.com
wrote:

On 2014-05-08 18:24, Andy Parker wrote:

On Tue, Aug 5, 2014 at 8:18 AM, Erik Dalén
erik.gustav.da...@gmail.com mailto:erik.gustav.da...@gmail.com
mailto:erik.gustav.dalen@__gmail.com
mailto:erik.gustav.da...@gmail.com wrote:

 On 5 August 2014 16:25, Reid Vandewiele

Re: [Puppet-dev] Decision: Near future of resource expressions

2014-08-05 Thread David Schmitt


On 2014-08-05 12:19, Erik Dalén wrote:




On 3 August 2014 22:18, Luke Kanies l...@puppetlabs.com
mailto:l...@puppetlabs.com wrote:

On Jul 28, 2014, at 6:43 AM, John Bollinger
john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:




On Friday, July 25, 2014 5:15:30 PM UTC-5, henrik lindberg wrote:


We reasoned that we already have create_resources in frequent
use to
solve real issues, so it is needed. I don't think
create_resources is
used simply because you can. Instead, it is because you do not
statically know the type, or you want to decide which
attributes to set
based on calculations you made. Both of those require
create_resources
function. Now it moves into the language.



For what it's worth, every use of create_resources() that I have
ever come across or thought about has involved a resource type
that is statically known.  The usual reason for create_resources()
is that the *identities* and properties of the resources need to
be dynamically determined.  That is, if I need or want to resort
to create_resources() then it's /usually/ because I don't know
statically which specific resources (of a known type) need to be
managed.  Sometimes I /also/ don't know which properties need to
be managed or maybe what their target values should be, but that's
secondary.


Exactly.  This is the more normal case, and is the one we should
optimize for.  And, IMO, the one that create_resources works just
dandily for.  I don’t see the need to promote a function to syntax
in this case.



 *= looks weird, even for Puppet.  What about contracting
it to *,
 parallel to the plussignment operator (+) and to the
ordinary value
 binding operator (=)?


The rationale is that you normally have:

name = value

Now, you do not have names, and * is often used as a
wildcard/splat/
split it up, implied, the name is picked from the hash, and
you may
want to line them up:

file { default:
  *= value ;

foo:
  mode = '0777' ;
  }

Does that make it feel better?



Somewhat, yes.  I at least get the mnemonic angle, but it still
seems weird.

Is this one operator *= or two * =?  If one, then are you
really going to permit splitting the operator into two tokens?  If
two, then is this splat operator the same one you described
elsewhere?  And what is the splat's operand in this context?

With this new, highly expressional approach, it seems like there
should be a way to do without the *= altogether.  I mean, if you
have a property name / value hash, then why shouldn't you be able
to plunk it down undecorated inside a resource instantiation
expression?  E.g.

file {
  default:
$file_defaults;
  foo:
mode = '0777';
}

or

file {
  default:
$general_file_defaults,
owner = 'ted';
  foo:
mode = '0777';
}

or even

file {
  default:
$general_file_defaults,
$mymodule_file_defaults,
owner = 'ted';
  foo:
mode = '0777';
}


Yeah, I’m not at all a fan of the ‘* = foo’ syntax.  It seems
strange in both the lexer and the parser, and it strikes me as a far
large change to the system without a large return.

If we conclude we need significantly more power in the resource
parameters, then I’d prefer to do something like formally treat it
as a hash, and support some kind of hash operations there.  E.g.,
something like:

file {
   default:
 $some_defaults + $other_defaults + {owner = ‘ted’};
   foo:
 mode = ‘0777’
}

This expands how we think about the RHS of a resource declaration,
but I think it’s more generically powerful and requires far less
specialized syntax.



As an example where this kind of expressiveness is needed:
https://github.com/spotify/puppet-puppetexplorer/blob/master/manifests/init.pp#L89-L97

Here I used it to allow the user to simply pass a hash with any
additional apache::vhost parameters as a parameter instead of exposing
all of them (and the usage of the hash() function is because puppet 3.x
doesn't allow variables as keys in hashes...).


But either of those proposed solutions could be used there I guess (*=
or default: pointing to a hash)


I like that piece of code as it is. Perhaps I would add a comment noting 
that $vhost_options is not allowed to override the base_vhost_options 
and give a reason for that. I needed to browse up to the parameter doc 
and think a bit about what that should mean.


I do not think the whole sequence would be any better with some kind of 
special operator, except perhaps for the hash() thingy, which I

Re: [Puppet-dev] if statement not being parsed when trying to select omit the ensure parameter from a resource.

2014-08-04 Thread David Schmitt


On 2014-08-02 06:19, Thom Luxford wrote:

The intention is for the the service running state after boot to be
optionally handled by puppet. Omitting the ensure parameter does this,
but why can't I add it when I need it like this?

service { $my_module::params::myServiceName:
 if $::my_service_ensure_running != 'undef' {
   ensure  = $my_module::my_service_ensure_running,
 }
 enable  = 'true',
 require = [ Package[$oscar_legacy::params::mysqlPackageName],
File[/etc/mysql/conf.d/mysqld_oscar_dbs.cnf] ],
   }

puppet parser validate {}
complains as so:

Error: Could not parse for environment production: Syntax error at
'::my_service_ensure_running'; expected '}' at
/home/oscara/git/puppetmaster/modules/my_module/manifests/init.pp:154


the if is a statement that cannot be used inside a resource definition.

Write it like this:

  service { $my_module::params::myServiceName:
enable  = 'true',
require = [ ...]
  }

  if $::my_service_ensure_running != 'undef' {
Service[$my_module::params::myServiceName]{
  ensure  = $::my_service_ensure_running,
}
  }

See the Puppet Language Reference 
(http://docs.puppetlabs.com/puppet/latest/reference/lang_conditional.html) 
for details.



Regards, David

--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/53DF7FF2.6070009%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Presenting a custom error message if source file in module does not exist

2014-08-04 Thread David Schmitt


On 2014-08-02 07:55, Craig Barr wrote:

TL;DR How do I output a custom error message for a failed assertion that
a source file exists. In other words, how do I display a nice error
message when puppet:///modules/mymodule/mysourcefile.txt does not exist


A great way to improve the situation would be to improve puppet to 
enumerate the locations it searched in the filesystem (perhaps only in 
the server log, to avoid leaking sensitive information) and file a 
jira-ticket + pull request.


If you only need it for a Very Special Case[tm], then you might be 
served by doing a special fail_unless_exists() function that you deliver 
with your module.



Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/53DF8095.5040907%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Decision: Near future of resource expressions

2014-08-01 Thread David Schmitt


On 2014-07-31 22:16, John Bollinger wrote:
[good points]

Just a quick note that I'm mainly agreeing with John's points: Automatic 
(and inconsistent) stringification of non-string-titles is weird and 
confusing, thus should be avoided. Automatic flattening of 
arrays-of-strings is weird, but probably not confusing, thus can be 
allowed, should be documented and discouraged (e.g. point in the docs to 
explicit flattening).



Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/53DB.9080408%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Metaparam Warning

2014-07-22 Thread David Schmitt


On 2014-07-22 00:28, Nan Liu wrote:

On Mon, Jul 21, 2014 at 2:30 PM, John Bollinger
john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:



On Monday, July 21, 2014 3:32:47 PM UTC-5, Nan Liu wrote:

Similar to the discussion of collect resources realize +
override, I wish the metaparameters weren't magically passed to
the resources, and we could choose to use them and pass the
behavior on as needed.



Sadly, it's not that easy.  Some metaparameters already aren't (or
shouldn't) be forwarded, mainly 'alias'.  On the other hand, many
others /must/ be forwarded in order to be effective ('tag', 'noop',
...).  The relational metaparameters could technically swing either
way, but the overall semantics need to maintain containment.

Schedule and loglevel are the only two that I think are ambiguous,
but more loglevel than schedule.  I'm not sure how it makes sense
for a resource to not inherit the schedule set on its container (if
there is one), else it's container's assigned schedule isn't fully
honored.  On the other hand, it does make sense for a resource to
have a different (lower) loglevel than its container, especially if
the container's is interpreted as an upper bound rather than an
exact log level for all messages.


The warning message seems to be a sign the behavior is not well defined
which leaves much to be desired. I was hoping there was some path forward:

1. Not supported, don't reuse metaparameter as class parameter.
Deprecate it, and enforce with failure.
2. Supported, metaparameter as class parameter pass behavior to
contained resources. In this scenario, I would argue metaparameter
should be allowed without being specified as a class parameter
explicitly (see ticket).
https://tickets.puppetlabs.com/browse/PUP-2556
3. Supported, metaparameter as class parameter behavior is configured by
user, support is enabled by specifying the parameter.

I'm not sure what are the other solutions beyond the three above, but
removing the ambiguity we have now would be an improvement.


I like #3, but despair when thinking about the easy failure modes 
(accidentally overwriting a metaparam with something completely different).


Maybe the way forward lies in treating the different kinds of metaparams 
- as John has enumerated - also differently:


  * must be forwarded in order to be effective ('tag', 'noop', ...):
These should not be overrideable. If someone further up has
set noop, nobody should be able to escape that (what about
collections in this dynamic scope? *shudder*)
Trying to have a define or class with such a parameter should be an
error.

  * aren't (or shouldn't) be forwarded, mainly 'alias':
Either it's allowable to override those, then remove the warning.
OR it's not allowed, then fail with an error.
Personally, I don't think 'alias' should be overrideable, but I have
no argument for that.

  * relational metaparameters could technically swing either way, but
the overall semantics need to maintain containment: This could
definitely be overridable, the user should be aware that he's
expected to maintain the semantics.



Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/53CE058C.4040006%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] RFC - Grammar quirks I want to remove...

2014-07-19 Thread David Schmitt


On 2014-07-18 03:00, Henrik Lindberg wrote:

Hi,

Boolean Attributes
---



Exported with whitespace
---


Kill both with fire.

Please.


Regards, David

--
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/53CA2FE4.5020900%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: RFC2 - Resource Defaults

2014-07-19 Thread David Schmitt


On 2014-07-17 23:41, Henrik Lindberg wrote:

On 2014-17-07 14:56, David Schmitt wrote:

On 2014-07-12 04:50, Henrik Lindberg wrote:

On 2014-11-07 10:55, David Schmitt wrote:


[...snip...]


[1] It might be worthwhile to start requiring to always write
'realize(Type| expr |)' for this side-effect. This looks annoying.


it could be

   Type | expr |.realize


Ugh.


A positive Ugh, or a Ugh of agonizing pain? :-)


The latter.

[...snip ...]


I think this may just move the problem to dueling defaults, dueling
values, and dueling overrides. (This problem occurs in the binder and
there the problem is solved by the rules (expressed in the terms we use
here (except the term 'layer', which I will come back to):
- if two defaults are in conflict, a set value wins
- if two values are in conflict, an override wins
- if two overrides are in conflict, then the one made in the highest
layer wins.
- a layer must be conflict free


Don't you mean the highest layer with a value must be conflict free ?


yes, that is true, since some higher layer must resolve the issue. Not
meaningful to enforce resolution in every layer.


Good.


Highest (most important) layer is the environment, secondly all
modules - this means that conflicts bubble to the top, where a user
must resolve the conflict by making the final decision.

The environment level can be thought of as what is expressed in
site.pp, global or expressed for a  node (if we forget for a while
about all the crazy things puppet allows you to do with global scope;
open and redefine code etc).


If you mean what I think you mean, I think like it.

Another example to try to understand this:

   class somemodule { package { git: ensure = installed } }

   class othermodule { package { git: ensure = '2.0' } }

   node 'developer-workstation' {
 # force conflict on Package[git]#ensure here: installed != '2.0'
 include somemodule
 include othermodule

 # conflict resolved: higher layer saves the day
 Package[git] { ensure = '2.1' }
   }

How would the parser/grammar/evaluator understand which manifests are
part of what layer?



We will have a new catalog model (the result built by the new catalog
builder slated to replace the current compiler). There we have a richer
model for defining the information about resources. We also have a new
loader system that knows where code came from. Thus, anything loaded at
the environment level (i.e. node definitions) knows it is in a higher
layer.


Slick. The next question then is: How does the user know? ;-) And How 
fine-grained are levels? Each entry on the module path? Will I be able 
to query the puppetmaster for a report on which sources influenced (or 
did not influence) a specific value?


[snip]


If we make variables be part of the lazy logic you would be able to
write:

   $a = $b + 2
   $b = 2

I think this will confuse people greatly.


Hehe, I can imagine that. When accessing variables across files/classes
I do not see that as a big problem, though. Within a single file/scope
it can be forbidden, or at least warned/linted.


We will see what we end up with - this is currently not a primary
concern. One neat thing you can do with the future parser (and in 4.0)
is to evaluate code in a local block using the function 'with', and then
pass it arguments, the variables in the lambda given to with are all
local! Thus you can assign the final value from what that lambda returns.


I see, I'll have to read up on the future parser...


The crux here is that just having one expression being followed by
another - e.g:

   1 1

is this a call to 1 with 1 as an argument, or the production of one
value 1, followed by another?


Is the parser and the evaluator so intertwined that that cannot be
interpreted in context? 1 is not a callable, therefore it cannot be a
function call.


They are not intertwined except that the parser builds a model that the
evaluator evaluates. The evaluator does exactly what you say, it
evaluates the LHS, and if that is not a NAME it fails, and if the NAME
is not a reference to a Function it fails. But the evaluator can not do
that in general, there may be a sequence of say if statements, they all
produce a value, should the second if be an argument to attempting to
call what the first produced ?

   if true { teapot }
   if true { 'yes I am'}

The evaluator would have no way of knowing, except doing static analysis
(which limits the expressiveness).

Currently the parser rewrites NAME expr, or NAME expr ',' expr ... into
a function call. I do not want to add additional magic of the same kind
if it can be avoided.


Accepted.

[snip]


I am hacking on ideas to fix the problematic constructs in the grammar.
I have had some success, but it is to early to write about. Will come
back when I know more.


Good hunting!


Regards, David

--
You received this message because you are subscribed to the Google Groups Puppet 
Developers group.
To unsubscribe from this group and stop receiving emails

Re: [Puppet-dev] Re: RFC2 - Resource Defaults

2014-07-19 Thread David Schmitt


On 2014-07-18 02:01, Henrik Lindberg wrote:
[snip]

As David Schmitt pointed out, having to use multiple variables is a pita
in several use cases because imperative programming (discrete steps) has
to be taken to get the task done. We eventually would end up with
something F# or Haskel like, or something resembling Prolog, since doing

[snip]


You say that as if it were something bad./tongue-in-cheek



Regards, David

--
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/53CA3244.1080508%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: RFC2 - Resource Defaults

2014-07-17 Thread David Schmitt


On 2014-07-12 04:50, Henrik Lindberg wrote:

On 2014-11-07 10:55, David Schmitt wrote:

I really dig this idea. Reading it sparked a crazy idea in the
language-designer part of my brain: What about going even further and
making the RHS also an Expression?

In the grammar basically everything would become a function call or just
a sequence of expressions. For the expressiveness of the language it
might do wonders:


Yes, that is how everything else works, but cannot because of the
ambiguity in hash vs. resource body/bodies (in the two different shapes
for regular, override/defaults).


   $ref = File[id]
   $select = File|title == id|
   $ref == $select # true
   $type = File


Yes, except we will have issues with the query (it is lazy now). We
either need to make it evaluate immediately, or make the return value
a Future.


   $values = { id = { mode = 0664, owner = root } }
   # equivalent hash shortcut notation for backwards compat and
   # keystroke reduction
   $values = { id: mode = 0664, owner = root }


Ah, neat idea make { x: y = z } mean the same as {x = { y = z}} !


   $defaults = { owner = def, group = def }
   $overrides = { mode = 0 }

   $final = hash_merge($values, { default: $defaults })


Did you mean?
 hash_merge($defaults, $overrides)

(which btw is the same as $defaults + $overrides).
Or, was that an example of a special instruction to the hash_merge to
treat a key of literal 'default' as things that do not override (i.e.
all other keys override, but 'default' defines what to pick if nothing
defined. If so, This is easily expressed directly in the language like
this:

 $final = $defaults + $values + $overrides


Ah, nice! Actually I was thinking of something completely different, but 
this is better.



   # old style
   create_resources($type, $values, $defaults)
   # basic resource statement
   $type $final

This is problematic, we cannot make any sequence a function call without
requiring that every expression is terminated with punctuation (e.g.
';') - but that must then be applied everywhere.



You are right, having that in the grammar makes no sense. I still think 
it is a neat detail to keep in mind when thinking about the underlying 
structure of what we're building.



   # interpreted as function call
   $type($final)


This is problematic because:
- selecting what to call via a general expression has proven in several
languages to be a source of thorny bugs in user code.


Conceded.


   # override chaining
   $ref $overrides
   $select $overrides

   # if create_resources would return the created resources:

It should.


   $created = create_resources($type, $values, $defaults)
   $created $overrides

   # replace create_resources
   File hiera('some_files')

   # different nesting
   file { /tmp/foo: $value_hash }

   # extreme override chaining
   File['/tmp/bar']
   { mode = 0644 }
   { owner = root }
   { group = root }

   # inverse defaulting
   file { [ '/tmp/1', '/tmp/2' ]: } { mode = 0664, owner = root }

   # define defined()
   defined(File['/tmp/bar']) == !empty(File|title == '/tmp/bar'|)

This would require unifying the attribute overriding semantics as almost
everything would become a override.

It would also lift set-of-resources as currently used in simple
collect-and-override statements to an important language element as
almost everything touching resources would return such a set.

Formalizing this a little bit:

   * 'type' is a type reference.
   * 'Type' is the list of resources of type 'type' in the current
 catalog (compilation).

This is actually a reference to the set that includes all instances of
that type (irrespective of if they actually exist anywhere). Something
needs to narrow that set to in the catalog (which is actually several
sets; realized, virtual, exported from here, imported to here, ...). To
get such a set, there should be a query operator (it operates on a
container and takes a type and predicates for that type).


   * 'Type[expr]' is the resource of type 'type' and the title equal
 to the result of evaluating 'expr'

yes

   * 'Type| expr |' is the list of local resources of type 'type' in
 the current compilation where 'expr' evaluates true. As a
 side-effect, it realizes all matched virtual resources.[1]

Some sort of query operator. If we keep the | |, it could mean
selection of the virtual here container/subset, currently it is
everything defined here.


If functions can return sets of resources that can be manipulated, the 
special query operator syntax can be abolished - or at least 
de-emphasised. See Eric's puppetdbquery for an example.



   * 'Type| expr |' is the list of local and exported resources of
 type 'type' where 'expr' evaluates true. As a side-effect,
 it realizes all matched exported resources.[2]

Same comment as above, but using a different container.


   * '{ key = value, }' is a simple hash ('hash')
   * '{ title: key = value, }' is a hash-of-hashes. Let's call

Re: [Puppet-dev] RFC2 - Resource Defaults

2014-07-11 Thread David Schmitt


Hi *,

On 2014-07-07 03:26, Henrik Lindberg wrote:

The egrammar (as well as the current grammar in 3x) tries to be helpful
by recognizing certain combinations as illegal (an override that is
virtual or exported), a resource default or override cannot specify a
title. This unfortunately means that the grammar has to recognize
sequences of tokens that makes this grammar ambiguous and it has to be
solved via operator precedence tricks (that makes the problem show up as
other corner cases of the grammar). (This is a classic mistake of trying
to implement too much semantics in the grammar / parser).

So...

What if we simply made the three resource expressions (create resource,
set resource defaults, an resource override) have exactly the same
grammar, and push of validation to the static validation that takes
place and the runtime.

Basically the grammar would be (I am cheating just a little here to
avoid irrelevant details):

 ResourceExpression
   : At? left_expr = Expression '{' ResourceBodies ';'? '}'
   ;

 ResourceBodies
   : ResourceBody (';' ResourceBody)*
   ;

 ResourceBody
   : title = Expression ':' AttributeOperations ','?
   ;

 AttributeOperations
   : AttributeOperation (',' AttributeOperation)*
   ;

 AttributeOperation
   : AttributeName ('=' | '+') Expression

 AttributeName
   : NAME |  KeywordsAcceptableAsAttributeName
   ;

 # Details here irrelevant, meaning is: virtual or exported resource
 # AT is the '@' token
 At
   : AT
   | AT AT
   | ATAT
   ;

So, how are the three kinds expressed? Notice that a title is required
for each ResourceBody. So we are basically going to handle different
combinations of left_expr and titles. We simply evaluate the left_expr
at runtime and treat the combinations of the *resulting* type and type
of title:

[...]

Since what I propose simply evaluates the left expression there is no
reason to deny certain expression in this place, and it is possible to
use say a variable as indirection to the actual type.

   $a = Notify
   $a { hi: message = 'hello there' }

(Which is *very* useful to alias types). Strings can also be used - e.g.

   'notify' { hi: message = 'hello there'}

which also makes the grammar more symmetric (a bare word like notify is
just a string value i.e. 'notify'). (We still would not allow types
to have funny characters, spaces etc. but it is at least symmetrical).



I really dig this idea. Reading it sparked a crazy idea in the 
language-designer part of my brain: What about going even further and 
making the RHS also an Expression?


In the grammar basically everything would become a function call or just 
a sequence of expressions. For the expressiveness of the language it 
might do wonders:


  $ref = File[id]
  $select = File|title == id|
  $ref == $select # true
  $type = File

  $values = { id = { mode = 0664, owner = root } }
  # equivalent hash shortcut notation for backwards compat and
  # keystroke reduction
  $values = { id: mode = 0664, owner = root }
  $defaults = { owner = def, group = def }
  $overrides = { mode = 0 }

  $final = hash_merge($values, { default: $defaults })

  # old style
  create_resources($type, $values, $defaults)
  # basic resource statement
  $type $final
  # interpreted as function call
  $type($final)
  # override chaining
  $ref $overrides
  $select $overrides

  # if create_resources would return the created resources:
  $created = create_resources($type, $values, $defaults)
  $created $overrides

  # replace create_resources
  File hiera('some_files')

  # different nesting
  file { /tmp/foo: $value_hash }

  # extreme override chaining
  File['/tmp/bar']
  { mode = 0644 }
  { owner = root }
  { group = root }

  # inverse defaulting
  file { [ '/tmp/1', '/tmp/2' ]: } { mode = 0664, owner = root }

  # define defined()
  defined(File['/tmp/bar']) == !empty(File|title == '/tmp/bar'|)

This would require unifying the attribute overriding semantics as almost 
everything would become a override.


It would also lift set-of-resources as currently used in simple 
collect-and-override statements to an important language element as 
almost everything touching resources would return such a set.


Formalizing this a little bit:

  * 'type' is a type reference.
  * 'Type' is the list of resources of type 'type' in the current
catalog (compilation).
  * 'Type[expr]' is the resource of type 'type' and the title equal
to the result of evaluating 'expr'
  * 'Type| expr |' is the list of local resources of type 'type' in
the current compilation where 'expr' evaluates true. As a
side-effect, it realizes all matched virtual resources.[1]
  * 'Type| expr |' is the list of local and exported resources of
type 'type' where 'expr' evaluates true. As a side-effect,
it realizes all matched exported resources.[2]
  * '{ key = value, }' is a simple hash ('hash')
  * '{ title: key = value, }' is a

Re: [Puppet-dev] Windows and Root Path (/) - Should we do this?

2014-07-04 Thread David Schmitt


On 2014-07-03 22:04, Rob Reynolds wrote:

Regarding

You can't create any fact that is going to allow you to set the path
like so /temp/somedirectory and use it across both windows and
*nix. Or can you?

https://tickets.puppetlabs.__com/browse/PUP-855?__focusedCommentId=79712page=__com.atlassian.jira.plugin.__system.issuetabpanels:comment-__tabpanel#comment-79712

https://tickets.puppetlabs.com/browse/PUP-855?focusedCommentId=79712page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-79712


$::systemdrive is empty on non-windows nodes, so ${::systemdrive}/tmp
would always be a valid path.

My developer soul just died a little bit saying that.


Unless someone defines it as a custom fact :(
Most likely they wouldn't, so that would less branching.


There is a special place where people who redefine core facts should go.



Regards, David

--
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/53B70922.8030902%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: RFC - Resource Defaults and Collection

2014-07-04 Thread David Schmitt


On 2014-07-04 18:31, Erik Dalén wrote:

Due to the dynamic scoping of them I only really use them for setting
global defaults. And some mechanism for doing that is really needed.


I've used to do that to set file buckets and Exec#path. But importing 
modules really put a stop to that as I saw that I didn't really need that:



https://github.com/DavidS/dasz-configuration/blob/master/manifests/site.pp





Using them inside classes is really mostly syntactic sugar to get the
code shorter. But I've also seen them used to conditionally set an
attribute. So not set it to value or undef, to set it to value or not
set it at all, as that has slightly different semantics. But that would
also really be better to do with some sort of postfix if condition in
the resource declaration.


Like this:

  file { /foo: ;}

  if $x { File[/foo] { source = $x } }

?

See


https://github.com/DavidS/dasz-configuration/blob/master/modules/hosting/manifests/customer_service.pp#L17


for a more elaborate example.


Regards, David

--
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/53B70B37.20309%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Windows and Root Path (/) - Should we do this?

2014-07-03 Thread David Schmitt


On 2014-07-02 20:15, Rob Reynolds wrote:

On Wed, Jul 2, 2014 at 7:49 AM, David Schmitt da...@dasz.at [13]
wrote:


Hi Rob,

The alternative would be to provide many of the well-known paths on
windows as facts.

file { ${::systemdrive}/somepath/bob: ... }

Not an obvious improvement.

A different question: is %PROGRAMFILES% always on %SYSTEMDRIVE% and
will people tend to write

file { /Program Files/...: }
file { /Windows/...: }

expecting it to work?


Its not and thats what this discussion is about. This is what makes 
it

non-deterministic. And makes it possibly an undesirable change.

The big question is how often do folks usually move things from the
default system drive with how often would those same folks fall into
the category of using /Program Files and expecting it to work?


After this reframe of the question, I can answer with my 
opinionated-module-author-hat on that abbreviating ${::systemdrive} to 
slash-at-the-beginning-of-a-path is a feature that I wouldn't touch with 
a long stick.


Besides the implicit-magic argument, I posit this snippet from one of 
my (admittedly linux) modules:


  
https://github.com/DavidS/dasz-configuration/blob/master/modules/hosting/manifests/customer.pp#L122


all paths there are based on some $base_dir which is a parameter to 
this type. This is a common pattern for me to reduce repetitiveness and 
enable reuse in different scenarios.


Considering use cases:

  * Many files on $systemdrive are within well-known directories. Those 
have their own envvar/fact that should be preferred.
  * a custom installation of something. Can be DRY'ed[1] by using 
$base_dir and/or requires (external) parametrization anyways.
  * fiddle in some foreign/third-party directory on $systemdrive. 
Already getting into thin-ice territory, arguments from previous point 
apply.


but then I've yet to use puppet on windows for more than the most basic 
things, so I might be missing important use cases that just haven't 
surfaced over here yet.



Regards, David

[1] http://c2.com/cgi/wiki?DontRepeatYourself


So Im leaning more on the side of requiring explicit paths and
against magic.

Regards, David

On 2014-07-01 21:28, Rob Reynolds wrote:


Context,
Awhile ago I thought it might be a good idea to allow for some
more
consistency in manifests where you would not need to specify the
drive
letter if you were going to the system drive on windows (usually
c: as
in c:/).

This is encapsulated in PUP-855[1].

This would allow for the ability to specify paths in somewhat the
same
way as they are specified on other systems, with the knowledge
that on
Windows, the / on the front of the path (/somepath/bob) would
actually be translated to SYSTEMDRIVE, most times c:/
(c:/somepath/bob).

There is concern that this is non-deterministic and could
possibly be
a problem, but this could potentially be useful for most folks.

Thoughts? Feedback?

[1] https://tickets.puppetlabs.com/browse/PUP-855 [1] [1]

--

Rob Reynolds

Developer, Puppet Labs

JOIN US AT , SEPTEMBER 20-24 IN SAN FRANCISCO

_Register by July 31st to take advantage of the Early Bird
discount
[2] __--__save $249!_

--
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 [2] [3].

To view this discussion on the web visit






https://groups.google.com/d/msgid/puppet-dev/CAMJiBK6YGz42hFL3JJ%2B%3D4nXriZ69ZcPYo1dQA6znpfxCU%2BRG5w%40mail.gmail.com

[3]
[4].
For more options, visit https://groups.google.com/d/optout [4]
[5].

Links:
--
[1] https://tickets.puppetlabs.com/browse/PUP-855 [5]
[2] https://puppetconf2014.eventbrite.com/?discount=EarlyBird [6]
[3] mailto:puppet-dev+unsubscr...@googlegroups.com [7]
[4]






https://groups.google.com/d/msgid/puppet-dev/CAMJiBK6YGz42hFL3JJ%2B%3D4nXriZ69ZcPYo1dQA6znpfxCU%2BRG5w%40mail.gmail.com?utm_medium=emailutm_source=footer

[8]
[5] https://groups.google.com/d/optout [9]


--
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 [10].
To view this discussion on the web visit



https://groups.google.com/d/msgid/puppet-dev/4f489b7dd0e881b2c7ccf00f02cf04dd%40hosting.edv-bus.at

[11].

For more options, visit https://groups.google.com/d/optout [12].


--

Rob Reynolds

Developer, Puppet Labs

JOIN US AT , SEPTEMBER 20-24 IN SAN FRANCISCO

_Register by July 31st to take advantage of the Early Bird discount
[14] __--__save $249!_

 --
 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 [15].
 To view this discussion on the web visit

https://groups.google.com/d/msgid/puppet-dev/CAMJiBK4X

Re: [Puppet-dev] Re: RFC - Resource Defaults and Collection

2014-07-03 Thread David Schmitt

On 2014-07-02 21:55, John Bollinger wrote:

at the point where affected resources
are declared (for Lindberg-style defaults) or at the point where the
defaults themselves are declared (for Schmitt-style defaults, if I
understand that proposal correctly).

My proposal would actually collapse those two points: the values only
affect the resources declared in the same resource block as the values
themselves. I'll explain my example more:

No defaults:

file {
/tmp/foo:
content = 'foo',
mode= 0321,
owner = weird;

/tmp/bar:
content = 'bar',
mode= 0321,
owner = weird;
}

equivalent Schmitt-style shortcutting:

file {
# defaults block (no title!)
mode = 0321,
owner = weird;

# actual resources block (no mode, owner)
/tmp/foo: content = 'foo';
/tmp/bar: content = 'bar';
}

the weird owner and mode do not apply to any resources outside of this
File declaration.
The resulting resource would not remember whether the parameter value
was set directly (content in the example) or with a shortcut (mode,
owner).

Any way around, I think there will be a major upheaval when the scope
of
resource defaults changes. Would it at least be possible for their
scope
to continue to extend into defined type instances declared within
their
lexical scope? That would mitigate the problems a bit, without
causing any
unpredictable evaluation-order dependencies. That would also be
consistent
with how the metaparameters of a defined-type instance are forwarded
to the
resources it contains. The semantics of wrapper definitions will
otherwise

change significantly, yet subtly.

I can only remember *seeing* Defaults in modules when they leaked to
somewhere I didn't want them to. That's probably the root cause for my
idea of really restricting where the default values can go.

Regards, David

--
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/8955769e2a9cd58dfda550454d3a9337%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Windows and Root Path (/) - Should we do this?

2014-07-03 Thread David Schmitt

On 2014-07-03 16:59, Rob Reynolds wrote:

but then I've yet to use puppet on windows for more than the most
basic things, so I might be missing important use cases that just
haven't surfaced over here yet.

No, I think you are onto something. For external modules it wouldn't
be a good idea. But interestingly enough, before reading this I sort
of came to the same conclusion.
https://tickets.puppetlabs.com/browse/PUP-855?focusedCommentId=79712page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-79712
so glad to see that it is already a pattern. :)

I'll update my comment to reflect your notes here.

Regarding

You can't create any fact that is going to allow you to set the path
like so /temp/somedirectory and use it across both windows and
*nix. Or can you?
https://tickets.puppetlabs.com/browse/PUP-855?focusedCommentId=79712page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-79712

$::systemdrive is empty on non-windows nodes, so ${::systemdrive}/tmp
would always be a valid path.

My developer soul just died a little bit saying that.

Regards, David

--
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/53B5B6A6.8040500%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: RFC - Resource Defaults and Collection

2014-07-02 Thread David Schmitt


On 2014-07-01 17:14, Henrik Lindberg wrote:

On 2014-01-07 8:52, David Schmitt wrote:

On 2014-06-28 16:54, Henrik Lindberg wrote:

...
What we want to do:
---

* Make application of defaults eager so that when a resource is
instantiated, it will immediately get the registered and visible
defaults (for missing attributes), at *that* point of time in the
evaluation. This means that defaults become imperative (like 
variable

assignment).


Do I understand this correctly, that after

   File { mode = 0664 }
   file { /tmp/foo:; }
   File { owner = bin }
   file { /tmp/bar: mode = 0755; }

the actual resources will look like

   file {
 # receives mode from first, but not owner from second
 /tmp/foo: mode = 0644, owner = root;
 # locally defines mode, but gets owner from second
 /tmp/bar: mode = 0755, owner = bin;
   }


Yes, that is the idea.


and later trying to override any of those attributes (e.g. in a
inherits) will fail?


There are two situations for overrides using Resource Override (i.e.
File['tmp/foo'] { ... = ... }). In general, only unset attributes 
can

be overridden. Unsure if it is allowed currently to override a set
attribute in an inherited class (need to investigate).


John seems to have done more reading on this topic. If it turns out to 
be true that subclasses can change already set attribute values (at 
least + will do so anyways), the Foo[x][y] is already in a deep 
hellhole of undefinedness and evaluation order dependency.


* When resource defaults are applied eagerly they are also 
available
when doing collection (instantiation is naturally done before 
collection

- otherwise there is nothing to collect).


There should be no difference between

   File { mode = 0644 }
   File | title == 'example' |

and

   File | title == 'example' | { mode = 0644 }

except, perhaps that the latter could create an error when mode is
already set on @file ?


The current implementation allows any attribute to be set, even those
that are already set. The principle seems to be that immutability
kicks in when a resource is realized.

So, the two cases you show would not be equivalent. The first would 
set

mode to '0644' for File[example] if it was not already set, and the
second would enforce that it was set to '0644'.


Hmmm ...

@file { /tmp/fail: content = '', tag = [ 'example1', 'example2' 
]; }

File | tag == 'example1' | { mode = 0644 }
File | tag == 'example2' | { mode = 0755 }

puppet (apply, 3.1.1) will create /tmp/fail with 0755. Changing the 
order of the two collectors changes the mode of /tmp/fail.



* There are edge cases where collection can be made at a point 
where all
resources that the query matches (will match) have not yet been 
created

(i.e. if the virtual resources are instantiated after the query is
evaluated). There seems to be logic that tries to find everything
(lazily at the end), but it is uncertain that it actually works
correctly in all cases. What we propose for the defaults have no 
effect

on this, it only changes what the resource attributes are when
collecting.


Seems obvious when applying defaults immediately.


* We want to change the function 'defined' to return the state of 
the

resource instead of just a boolean. Currently the concept of being
defined is vague, the function returns true for all kinds of 
resources

(virtual and exported) as well as those that are included in the
catalog. We want to return some kind of status (that is truthy to 
make

it backwards compatible), but that also tells if the resource is
actually realized (in the catalog). (We agree that using the 
defined

function is bad practice, but it is required to support certain
use-cases that would otherwise be very painful/impossible to 
handle).


I think the most common use for defined is is this resource 
already
part of the catalog up until now. I'm not totally sure why you want 
to
burden the Defaults story with *this* can of worms, but I think it 
might
be clearer to deprecate defined in its current form and replace it 
with

specific functions that inspect the current compilation state.

Now, the function lies - it says that virtual (unrealized) resources 
are

also in the catalog, which is not really true. (The concept of
being defined is very loosely, uhm... defined)


I'm not saying it shouldn't be fixed (probably 4.0 is a good target to 
do so; creating warnings for the wrong cases in 3.7). I'm just saying 
that I don't see the connection to resource defaults.


* The File[foo][mode] syntax for lookup of a resource attribute 
will be
more sane, as it will correctly produce the value at that point in 
time
in the evaluation. It is either the value (explicit or default) 
that
will end up in the catalog for a realized resource, or the explicit 
or

default value of an unrealized virtual resource that *may* get a
different value when it is later realized (if realized at all). 
Thus,
with a combination of being able to know if a resource

Re: [Puppet-dev] Windows and Root Path (/) - Should we do this?

2014-07-02 Thread David Schmitt


Hi Rob,

The alternative would be to provide many of the well-known paths on 
windows as facts.


  file { ${::systemdrive}/somepath/bob: ... }

Not an obvious improvement.

A different question: is %PROGRAMFILES% always on %SYSTEMDRIVE% and 
will people tend to write


  file { /Program Files/...: }
  file { /Windows/...: }

expecting it to work?

So I'm leaning more on the side of requiring explicit paths and against 
magic.


Regards, David

On 2014-07-01 21:28, Rob Reynolds wrote:

Context,
 Awhile ago I thought it might be a good idea to allow for some more
consistency in manifests where you would not need to specify the 
drive
letter if you were going to the system drive on windows (usually c: 
as

in c:/).

This is encapsulated in PUP-855[1].

This would allow for the ability to specify paths in somewhat the 
same
way as they are specified on other systems, with the knowledge that 
on

Windows, the / on the front of the path (/somepath/bob) would
actually be translated to SYSTEMDRIVE, most times c:/
(c:/somepath/bob).

There is concern that this is non-deterministic and could possibly be
a problem, but this could potentially be useful for most folks.

Thoughts? Feedback?

[1] https://tickets.puppetlabs.com/browse/PUP-855 [1]

--

Rob Reynolds

 Developer, Puppet Labs

JOIN US AT , SEPTEMBER 20-24 IN SAN FRANCISCO

_Register by July 31st to take advantage of the Early Bird discount
[2] __--__save $249!_

 --
 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 [3].
 To view this discussion on the web visit

https://groups.google.com/d/msgid/puppet-dev/CAMJiBK6YGz42hFL3JJ%2B%3D4nXriZ69ZcPYo1dQA6znpfxCU%2BRG5w%40mail.gmail.com
[4].
 For more options, visit https://groups.google.com/d/optout [5].


Links:
--
[1] https://tickets.puppetlabs.com/browse/PUP-855
[2] https://puppetconf2014.eventbrite.com/?discount=EarlyBird
[3] mailto:puppet-dev+unsubscr...@googlegroups.com
[4]

https://groups.google.com/d/msgid/puppet-dev/CAMJiBK6YGz42hFL3JJ%2B%3D4nXriZ69ZcPYo1dQA6znpfxCU%2BRG5w%40mail.gmail.com?utm_medium=emailutm_source=footer
[5] https://groups.google.com/d/optout


--
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/4f489b7dd0e881b2c7ccf00f02cf04dd%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] RFC - Resource Defaults and Collection

2014-07-01 Thread David Schmitt


Hi Henrik,

On 2014-06-28 16:54, Henrik Lindberg wrote:

Hi,
We (the server-team) have started to dig into the area of Resource
Defaults and Collection in our work on 3.7's future parser/evaluator
(and what will become Puppet 4.0).


thanks for taking up this topic. As I'm a heavy user of export/collect, 
Defaults were always taboo for my modules, due to many of the reasons 
you're listing below.



We believe that there is an opportunity to improve on how Puppet now
works, and make it less confusing. We are not yet completely sure about
edge use-cases and the implications of what we would like to do - so we
would very much like to get your feedback.

Puppet currently allows setting defaults for resources - e.g.

 File { mode = '0666' }

* These can also be set for user defined types.

* It is possible to make multiple such statements for the same resource
type, but additional statements may not set the same attributes

* When a default statement is evaluated, it is registered in its closure
scope (i.e. where it is located in source). e.g. a resource created in
Class a, gets defaults that are visible in the scope of Class a.

* All resources defined in that scope will potentially be affected by
those defaults (i.e. if the are found to have missing values at the end
of the compilation).

* At the end of the compilation, all resources will be processed and any
missing values are set from the registered defaults (from the
perspective of the resource's containment scope (i.e. where it was
defined).

What are the problems with this?
---

* Defaults are applied after collection, thus if you try to use + to
add to a virtual resource's attribute, the resource value(s) for the
attribute you are trying to append to will not include the defaults. As
you are also setting/overriding the values with the collection, the
default values are not included in the values, and you have to repeat
them (if they should be included).

* You cannot query (or so we suspect - we have to investigate to be
sure) for values that will be set via the defaults, so the collection
will miss the resources that later (after collection is completed) will
be given a value that would have made it included in the collection.

* It is possible to reopen classes, and introduce additional default
expressions after resources have been instantiated (but not evaluated).
This affects the attribute values the resources will end up having in
the catalog. (At some point later, we will make it an error to reopen a
class, but we don't think we will be able to fix this in time for 4.0).

* Evaluation of Collection Expressions is intertwined with resource
evaluation (same priority in the lazy evaluation queue), and it is
possible to play tricks with virtual resources, defaults and collections
that will (even if there is an attempt at considering potential defaults
when querying) never be able to consider such information that arrived
after the fact.

* Collection can be an operand in a dependency, and thus be evaluated
even later than the application of defaults.

Or, in other words: it is really confusing.

What we want to do:
---

* Make application of defaults eager so that when a resource is
instantiated, it will immediately get the registered and visible
defaults (for missing attributes), at *that* point of time in the
evaluation. This means that defaults become imperative (like variable
assignment).


Do I understand this correctly, that after

  File { mode = 0664 }
  file { /tmp/foo:; }
  File { owner = bin }
  file { /tmp/bar: mode = 0755; }

the actual resources will look like

  file {
# receives mode from first, but not owner from second
/tmp/foo: mode = 0644, owner = root;
# locally defines mode, but gets owner from second
/tmp/bar: mode = 0755, owner = bin;
  }

and later trying to override any of those attributes (e.g. in a 
inherits) will fail?



* When resource defaults are applied eagerly they are also available
when doing collection (instantiation is naturally done before collection
- otherwise there is nothing to collect).


There should be no difference between

  File { mode = 0644 }
  File | title == 'example' |

and

  File | title == 'example' | { mode = 0644 }

except, perhaps that the latter could create an error when mode is 
already set on @file ?



* There are edge cases where collection can be made at a point where all
resources that the query matches (will match) have not yet been created
(i.e. if the virtual resources are instantiated after the query is
evaluated). There seems to be logic that tries to find everything
(lazily at the end), but it is uncertain that it actually works
correctly in all cases. What we propose for the defaults have no effect
on this, it only changes what the resource attributes are when collecting.


Seems obvious when applying defaults immediately.



* We want to change the function 'defined' to return the state of the
resource instead of just a boolean. Currently the concept

Re: [Puppet-dev] Re: Data binding for defines

2014-05-15 Thread David Schmitt


Hi,

On 16.05.2014 02:17, Alessandro Franceschi wrote:



On Thursday, May 15, 2014 9:55:05 PM UTC+2, John Bollinger wrote:



On Thursday, May 15, 2014 9:46:40 AM UTC-5, Alessandro Franceschi wrote:

Hallo everybody,
I've tried to look around in the group for past discussions
about this topic but haven't found any.
If this has been already debated , please forgive me and point
me to the right direction.

I wonder what do you thing about a feature request to have data
bindings also for defines' parameters.



I'm skeptical about their value.  We already have data bindings for
classes, by which resource parameters can (indirectly) be injected,
and I am inclined to think that classes are the right level of
abstraction.  On the other hand, we also have create_resources(),
which already can give you resource-level data binding if you want
to use it that way.

I do not favor drawing distinctions between defined resource types
and native resource types.  On that basis, I would argue for data
binding either for all resource types or for none, and against data
binding for only defined types.

I am concerned about the impact.  It is already somewhat costly for
Puppet to evaluate data bindings for class parameters, and adding
bindings for resource parameters (even just for resources of defined
types) will magnify that.  Note that the cost scales with the
aggregate number of defined parameters for all declared resources,
independent whether any data are actually bound.  In fact, the cases
were no data are bound are the most costly, because hiera must then
search the entire hierarchy.


Yes, these are valid and convincing points.
Anyway if we find data binding useful for classes and can bear the
performance overhead, I suppose we can do the same for defined types.


I very much like the idea for data binding on all parameters, but this 
statement is really not universally true. I've got catalogs with only 
tens of classes but thousands of resources. That works out to 100x more 
hiera calls. :-/



Regards, David

--
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/5375A109.7020209%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Announce: Puppet 3.5.0-rc2 Available.

2014-03-26 Thread David Schmitt

On 2014-03-26 11:09, Craig Dunn wrote:

### Global `$facts` Hash

You have to manually enable this (along with the `$trusted` hash) by
on your puppet master(s). Itll be on by default in Puppet 4.

In addition to using `$fact_name`, you can now use
`$facts[fact_name]` to get a fact value. The `$facts` hash is
protected and cant be overridden locally, so you wont need the `$::`
idiom when using this.

Our hope is that this will visibly distinguish facts from normal
variables, make Puppet code more readable, and eventually clean up
the global variable namespace. (Thatll take a while, though --- we
probably wont be able to disable `$fact_name` until, like, Puppet
5.)

Out of curiosity what is the reasoning behind making facts different
from normal variables? What is special about them compared to
top-level variables, hiera data or ENC variables? Whilst I think
having facts in their own protected namespace/hash is a long overdue
and very good idea, in my opinion having it scoped as a top-scope
hash

and referenced as $::facts[value] is not only more familiar to people
already using Puppet but is also a lot easier to understand than
making them special and referencing them as if they were locally
scoped - to me that makes the code less readable, rather than more.

Without being involved in the design of that, I'd venture that this is
backed by the same reason that PHP has recently removed
register_globals: avoid allowing lesser trusted parts of the system to
provide values in unexpected regions of the code.

Regards, David

--
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/21cc8fb5a7a4daf97c6369c1bb28827e%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] non-unique resource names: systemd user services, ssh keys

2014-03-18 Thread David Schmitt


On 2014-03-17 15:19, Felix Frank wrote:

On 03/17/2014 08:41 AM, David Schmitt wrote:
as a follow-up to the recent non-unique package name discussion, 
I've

noticed two further instances where this is a problem:

  * ssh_authorized_key, which is has only the comment (name) as
namevar. This is obviously easy to avoid in practice, but might 
run

into weird edge cases, e.g. blocking proper purge support.


Good point. Note that crontab had different but related issues wrt.
purging. We came up with a workaround then that we can likely apply 
to
authorized keys as well, i.e. mangle the titles of generated 
resources

into a shape that is unlikely to clash with real-word resources (and
other generated resources).


I've made a quick test and multiple namevars and title patterns do 
interact like I have imagined they would:


I've enhanced the type I'm currently working on (see my recent mail), 
by adding the second title pattern here:


  def self.title_patterns
[
  [ /^([-_\w\/]+)\.(\d+)$/ , [ [:parent_interface ], 
[:subinterface_number] ] ],

  [ /^([-_\w\/]+)$/ , [ [:parent_interface ] ] ], # added
  [ //, [] ]
]
  end

and now the following notations work all as the respective comments 
say:



  pan_subinterface {
ethernet1/5.17:
  comment   = 'title: ethernet1/5.17';

ethernet1/5.18:
  subinterface_number = '13',
  comment = 'title: ethernet1/5.18; 
subinterface_number: 13';


ethernet1/5:
  subinterface_number = '14',
  comment = 'title: ethernet1/5; parent_interface: 
ethernet1/5, subinterface_number: 14';


flubb_53:
  parent_interface = 'ethernet1/5',
  subinterface_number  = '3'
  comment   = 'title: flubb_53, parent_interface: ethernet1/5, 
subinterface_number: 3';

  }

Pan_subinterface['ethernet1/5'] and Pan_subinterface['ethernet1/5.18'] 
are very misleading titles in this specific case, but would be poster 
childs for resources like cron or authorized keys, where the 
non-colliding use case is much less confusing, because the title would 
map to a command or comment.


Example using ssh_authorized_key:

  # current situation
  ssh_authorized_key {
# no user: key goes to root
some_app:
  ensure = present,
  key= ...;

# specify user as property
some_user_app:
  ensure = present,
  key= ...,
  user   = flubb;

# unique title and name, specify user as property, comment will be 
flubb: power_key

flubb: power_key:
  ensure = present,
  key= ...,
  user   = flubb;

# unique title and name, specify user as property, comment will be 
buzz: power_key

buzz: power_key:
  ensure = present,
  key= ...,
  user   = buzz;

# title collision although configured for different user
buzz: power_key:
  ensure = present,
  key= ...,
  user   = froz;
  }

  # with title patterns and multiple namevars
  ssh_authorized_key {
# no user: key goes to root
some_app:
  ensure = present,
  key= ...;

# specify user as property
some_user_app:
  ensure = present,
  key= ...,
  user   = flubb;

# parse user flubb from title, comment will be power_key
flubb: power_key:
  ensure = present,
  key= ...;

# parse user buzz from title, comment will be power_key
buzz: power_key:
  ensure = present,
  key= ...;

# title collision although configured for different user
buzz: power_key:
  ensure = present,
  key= ...,
  user   = froz;
  }

There seem to be some gains, but I'm not sure, whether they translate 
to enough practical savings for the migration effort.




Regards, David

--
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/e7a6f4a7451dcf0704e39062fa34be79%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] non-unique resource names: systemd user services, ssh keys

2014-03-18 Thread David Schmitt

On 2014-03-18 10:33, Felix Frank wrote:

On 03/18/2014 10:20 AM, David Schmitt wrote:

# parse user flubb from title, comment will be power_key
flubb: power_key:
ensure = present,
key= ...;

This kinda made me frown. What would this manifest express then:

Ssh_authorized_key { ensure = present, user = customer }
ssh_authorized_key { admin: masterkey: key = ... }

(Also, what would a user expect it to express?)

This is indeed ugly. I've only discovered the current behaviour by
experimentation. This is definitely something that should be fixed in
one way or the other:

* title matches take priority, or
* properties set directly and via title are forbidden.

As for migration...this would be us looking at deprecating key
names
of the proposed form first. Granted, those are unlikely picks, but
any

user that *is* afflicted by such a deprecation will have to make some
handstands to cleanly move to a different naming scheme.

Now that I think more about it, I feel obliged to point out that adding
a second namevar and adding title_patterns are two separate issues.

Adding the namevar (and - IIRC - changing the Type#name getter) without
adding title_patterns for comment AND user syntax would create this
situation:

# with multiple namevars, but no title pattern
ssh_authorized_key {
# no user: key goes to root, use title as comment
some_app:
ensure = present,
key= ...;

# specify user as property, use title as comment
some_user_app:
ensure = present,
key= ...,
user = flubb;

# potentially conflicting resources

# specify user as property, use title as comment
flubb: power_key:
ensure = present,
user= flubb,
key = ...;

# use title without specific meaning
buzz: power_key:
ensure = present,
user= flubb,
comment = power_key,
key= ...;

# use title without specific meaning, collision with last resource
because of title

buzz: power_key:
ensure = present,
user= froz,
comment = power_key,
key= ...;

# use title without specific meaning, collision with last resource
because of properties

# not tested empircally
froz: power_key:
ensure = present,
user= froz,
comment = power_key,
key= ...;
}

This becomes more verbose, but would not require a migration. Having
written it down, I'm not sure what multiple namevars would bring to the
table. From my amateurish reading of Puppet::Type, they are used
internally to automatically distinguish resources. The code around this
is not very clear, or clearly documented.

Regards, David

--
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/6d62c2967a85ee47f6bd63be9cd3e6d7%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] We're changing the module community triage/meeting date and time!

2014-03-18 Thread David Schmitt

Hi,

am I correct that 10:00 PST is this:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140320T10p1=137
?

Regards, David

On 2014-03-18 16:50, Ashley Penney wrote:

Hi,

As some of you will know weve been copying the platform team and
doing

a weekly triage/meeting amongst the community to discuss current open
PRs, requests, code in progress, and simply trying to close PRs on
some of the popular modules.

We originally picked 0900 (PST) on Tuesdays to run this but it
clashes

with leaving work time for a lot of the european community members.
Were going to try moving this to:

1000 (PST) ON THURSDAYS

As before well continue to send out a hangout link an hour or so
before the hangout as well as make sure we paste it in #puppet-dev
for

everyone to come along and talk modules with us. Were hoping the
move to slightly later will help our commuting community guys!

Thanks,

https://groups.google.com/d/msgid/puppet-dev/CAPfZVDZoshkHqWG_n6pkJvfW1wa6qF_5_ReDxhmfbRkqU1kUyw%40mail.gmail.com
[2].
For more options, visit https://groups.google.com/d/optout [3].

Links:
--
[1] mailto:puppet-dev+unsubscr...@googlegroups.com
[2]

https://groups.google.com/d/msgid/puppet-dev/CAPfZVDZoshkHqWG_n6pkJvfW1wa6qF_5_ReDxhmfbRkqU1kUyw%40mail.gmail.com?utm_medium=emailutm_source=footer
[3] https://groups.google.com/d/optout

--
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/849353c4a1f1ebf804c8d87945335cf9%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] non-unique resource names: systemd user services, ssh keys

2014-03-17 Thread David Schmitt


Hi,
as a follow-up to the recent non-unique package name discussion, I've 
noticed two further instances where this is a problem:


  * ssh_authorized_key, which is has only the comment (name) as
namevar. This is obviously easy to avoid in practice, but might run
into weird edge cases, e.g. blocking proper purge support.

  * systemd --user service instances. I'm currently experimenting with
user serviceable systemd instances. The current service type is not
able to model this at all. For example, I've would have multiple
nginx.service instances (one for each customer), each of which
receive notifications from different sets of other resources.


Regards, David

--
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/5326A747.8010104%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: The 4x scope

2014-03-16 Thread David Schmitt


On 2014-03-16 01:36, Henrik Lindberg wrote:

Sure experienced programmers or people who are more familiar with how
the scoping model in Puppet works will be able to use this to their
advantage but the code that's produced and potentially released might
not be easy to understand for others.



Yeah, and how it works today is a mystery to most Puppet Users, even
experts are tripped up by some of the quirks.


Yes.


It will interesting to see how the different ideas works in practice. We
have a goal to not break every module in the initial release of 4x,
and having the new simpler/stricter lookup rules may be too much
breakage to tolerate and we have to introduce a legacy name resolution
option or something like that to help migration. Whatever we do we need
to make sure that a well formed 4x (not using any other new 4x features)
also work on 3x.



In the worst case, you could add a special option strict[1] sigil, to 
request strict lookup on a file-by-file basis for as long as legacy 
lookup has to be supported.


Would probably be a nightmare to support by the implementation though.



[1]http://stackoverflow.com/q/2454552

--
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/532559CC.6050007%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] The 4x scope

2014-03-14 Thread David Schmitt


On 2014-03-14 01:19, Henrik Lindberg wrote:

- What is your reaction to getting rid of dynamic/relative name
resolution? (Breakage vs. sanity...)


I totally support that $x can only be a local variable and $foo::x can 
only be $::foo::x.


I've been bitten a few times by having a local class name shadow a 
more global one. E.g: Given there is a bar class from the module with 
the same name. When adding a local modificator class foo::bar in the 
foo module, the name bar suddenly has change meaning throughout 
foo without any way to notice, except for super-humanly code review 
and weird breakage.



I sometimes use very local defines like this:

  class foo (...) {
define helper(...) {
  # ...
}

helper { $ary: foo = bar }
  }

I guess those could still fall under local references as long as they 
are defined within the braces of the surrounding class. Perhaps external 
reference to those should be forbidden anyways ;-)




Regards, David


--
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/532367CC.10803%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: The 4x scope

2014-03-14 Thread David Schmitt


On 2014-03-14 17:00, Henrik Lindberg wrote:

On 2014-14-03 11:48, Erik Dalén wrote:

Not terribly important, but are there any thoughts on making it so you
can order variables any way you like in the manifest? They are immutable
anyway, so these two examples should be equivalent:



I am also not sure if making the language completely lazy makes it any
easier for users with the different kind of corner cases (when to stop
iterating if there are loops in the logic, how to understand what is
wrong in those cases, etc.)


I can remember chatting with Markus in Ghent about the Futures parser 
where the compiler would have become completely lazy. My feeling is that 
to be useful no cycles would have to be allowed, thus making evaluation 
straightforward (computationally).



Regards, David

--
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/532368FD.90705%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] The 4x scope

2014-03-14 Thread David Schmitt


On 2014-03-14 17:44, Andy Parker wrote:

We also have to decide if any of the relative name-space
functionality should remain (i.e. reference to x::y is relative
to potentially a series of
other name spaces (dynamic scoping), or if it is always a
global reference when it is qualified.


Other than using the search() function (which I'm not sure it even
works), do you have an example of this happening? I can't seem to
cause it to occur. If it doesn't really exist, then I'm not too
concerned about dropping it :). I know that the relative name lookup
happens when finding classes (include(b) can refer to a::b), but
haven't been able to get it for variables yet.


Figured out a case of this happening:

   1 class a {
   2   include b
   3 }
   4
   5 class a::b {
   6   include c
   7   notice($c::x)
   8 }
   9
  10 class a::b::c {
  11   $x = 1
  12 }
  13
  14 include a

Line 7 ends up looking up the class c, which is looked up relative to
a::b and so it finds a::b::c and then it performs the $x lookup in that
class.

A consequence of this, which I think we should get rid of, is that
anything visible from a::b::c is able to be looked up in this fashion.
So another way of getting the kernel fact from a::b is to use $c::kernel
(or in the new fact hash that is introduced in 3.5.0 $c::facts[kernel]).


Yeah, that's what I was talking about in my other mail. Under certain 
patterns this can become quite common and quite painful, both in 
debugging and how the resolution looks like.



Regards, David

--
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/5323696B.1020904%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

2014-03-12 Thread David Schmitt


On 2014-03-12 02:13, Trevor Vaughan wrote:

If possible, I would love to see this done without a composite
namevar.

The issue is that youre going to start ending up with variables
*everywhere* to figure out what youre actually installing.


I'm not fully convinced that this is actually true.

I've now finished the composite type I was talking about earlier, and 
the missing corner stone was defining


  def name
#{parent_interface}.#{subinterface_number}
  end

on the type, so that the prefetched resources are matched up to the 
resources from the catalog.



If possible, I would like the same title but that should be smoothly
combined with the provider.

That said, if it ends up being a composite namevar, thats not the end
of the world. We just need to use a delimiter that isnt used in
package names. An @ maybe? Something wide makes it easy to read. The
cases where I used a composite namevar I used a plus. So, mysql+rpm,
which is quite easy to scan.

package { mysql@rpm: ... }


Without having it tested, it should be possible to specify multiple 
patterns to match on titles without '@' to set only the package name.


So the following should still work:

  package {
mysql:;
apache:
  package_name = 'apache2-mpm-itk';
nokogiri:
  provider = gem;
memcache:;
memcache@gem:;
  }

With the following correct references:

  * using the title:
Package['mysql']
Package['apache']
Package['nokogiri']
Package['memcache']
Package['memcache@gem']
  * using the actual name, which probably be very brittle as the 
provider is often defaulted based on facts

Package['mysql@rpm']
Package['apache2-mpm-itk@deb']
Package['nokogiri@gem']
Package['memcache@rpm']
Package['memcache@gem']
  * using queries; this is very explicit about the user's requirement, 
may return multiple resources

Package| title == 'mysql' |
Package| package_name == 'mysql' |
Package| package_name == 'mysql' and provider != 'gem' |
Package| package_name == 'memcache' |

I think there is no (trivial) way around the fundamental problem that 
Package['memcache'] cannot refer to a single resource when the package 
name is not unique.



I'm currently working through these issues (with a different type) in 
the project I'm working on, so I'd be very thankful about any 
enlightenment about problems you see with this approach.


Regards, David



Trevor

On Tue, Mar 11, 2014 at 5:23 PM, Pedro Côrte-Real pe...@pedrocr.net
[5] wrote:


On Tue, Mar 11, 2014 at 5:29 PM, Andy Parker a...@puppetlabs.com
[1] wrote:
 Personally, I would be ok with yet another hack in puppet 3 to
handle this
 issue since it has been coming up so often and since I also dont
know a
 clear timeline for getting new functionality in to address this
specific
 issue in a better way. And yes, my idealism is cracking :/

Its great to finally see traction on this. I still dont understand
why this is a hack though. This is what is broken:

package {foo_deb:
  name = foo,
  provider = apt,
}
package {foo_gem:
  name = foo,
  provider = gem,
}

But the only reason this doesnt work is that we used $name to
override the deb/gem name. This on the other hand would work fine:

exec {foo_as_root:
  command = /bin/foo,
  user = root,
}
exec {foo_as_someuser:
  command = /bin/foo,
  user = someuser,
}

Yet the only difference between the two cases is that we used
$command
and not $name to override the default given by $title.

Package was designed assuming the meaningless tokens we pass to apt
to
select debs have some relation to the meaningless tokens we pass to
gem to select gems. Most of the time this doesnt bite us because
names are reasonably unique. But then someone goes and uses
memcache
for the server deb and the client gem. These are totally different
software packages that just happen to use the same token in two
different package systems. Using $title as the default meaningless
token is economical in terms of keystrokes but then just like with
Exec there needs to be a not unique $meaningless_token variable.

This is just a bug in Package, fixing it isnt a hack.

Pedro

--
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 [2].
To view this discussion on the web visit



https://groups.google.com/d/msgid/puppet-dev/CALprHx_tTEKX%3D-%2B3iZiDDiWOS0fp20fT91TV%3DpWpd92eRNtVSA%40mail.gmail.com

[3].

For more options, visit https://groups.google.com/d/optout [4].


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com [6]

-- This account not approved for unencrypted proprietary information
--

 --
 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

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

2014-03-11 Thread David Schmitt

Talk about coincidence. Today I implemented this fragment of a custom 
type:


  def self.title_patterns
[
  [ /^([-_\w\/]+)\.(\d+)$/ , [ [:parent_interface ], 
[:subinterface_number] ] ],

  [ /.*/, [ ] ]
]
  end

  newparam(:parent_interface) do
desc The name of the parent interface, automatically parsed from 
the title.

newvalues(/^[-_\w\/]+$/)
isnamevar
  end

  newparam(:subinterface_number) do
desc The number of this subinterface, automatically parsed from 
the title.

newvalues(/^\d+$/)
isnamevar
  end

usage:

  blah_subinterface {
ethernet1/2.3: ...
  }

leads to this resource_hash:

  :parent_interface = 'ethernet1/2',
  :subinterface_number = '3',

without any further intervention on my side.

Awesome sauce.

This can be used like this too:

  blah_subinterface { important title:
parent_interface = 'ethernet1/2',
subinterface_number = '3',
...
  }

so, there seems nothing in the way of your use-case, no?


Regards, David


On 2014-03-09 21:10, Trevor Vaughan wrote:

Oh, no, this works perfectly. I just *hate* having to stuff all of
that into the name. It makes the hash of options completely 
pointless.


I want the name/title to be arbitrary and the rest to just work.
Unfortunately, I havent found the special sauce for this yet.
 
Trevor

On Sun, Mar 9, 2014 at 6:29 AM, David Schmitt da...@dasz.at [4]
wrote:


On 09.03.2014 03:39, Trevor Vaughan wrote:


In theory a composite namevar could be used if you just specify
the
provider.

For instance, on a Red Hat system:

package { foo: ensure = latest } == namevar == foo:yum

And

package { foo: ensure = latest, provider = gem } == namevar ==
foo:gem

That said, I never could get composite namevars to work this way.
I
always had to have a unique name which ended up in something
silly like
package { foo_rpm:} or package { foo_gem:} which, while it should
work, is absolutely horrible to read.


That was my understanding how composite namevars should have worked
from the beginning. Sadly, this seems too complex or not useful
enough to be actually implemented. It would even help for
multi-arch and multi-versions installations: foo:1.0:i386:yum vs
foo:2.0:amd64:yum.

Regards, David

--
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 [1].
To view this discussion on the web visit



https://groups.google.com/d/msgid/puppet-dev/531C426F.1000903%40dasz.at

[2].

For more options, visit https://groups.google.com/d/optout [3].


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com [5]

-- This account not approved for unencrypted proprietary information
--

 --
 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 [6].
 To view this discussion on the web visit

https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%40mail.gmail.com
[7].
 For more options, visit https://groups.google.com/d/optout [8].


Links:
--
[1] mailto:puppet-dev%2bunsubscr...@googlegroups.com
[2] 
https://groups.google.com/d/msgid/puppet-dev/531C426F.1000903%40dasz.at

[3] https://groups.google.com/d/optout
[4] mailto:da...@dasz.at
[5] mailto:tvaug...@onyxpoint.com
[6] mailto:puppet-dev+unsubscr...@googlegroups.com
[7]

https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%40mail.gmail.com?utm_medium=emailutm_source=footer
[8] https://groups.google.com/d/optout


--
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/c1984be94fd2d816e19a815490336b58%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

2014-03-10 Thread David Schmitt


On 2014-03-09 21:10, Trevor Vaughan wrote:

Oh, no, this works perfectly.


Seems like I have some reading to do, or, see below.


I just *hate* having to stuff all of
that into the name. It makes the hash of options completely 
pointless.



I want the name/title to be arbitrary and the rest to just work.
Unfortunately, I havent found the special sauce for this yet.


  package {
'foo:yum':
  name = 'foo',
  provider = 'yum';

'foo:gem':
  name = 'foo',
  provider = 'gem';
  }

gives me

  Error: Could not retrieve catalog from remote server: Error 400 on
  SERVER: Puppet::Parser::AST::Resource failed with error 
ArgumentError:
  Cannot alias Package[foo:gem] to [foo] at 
/vagrant/vagrant/manifests/
  site.pp:127; resource [Package, foo] already declared at 
/vagrant/
  vagrant/manifests/site.pp:127 at 
/vagrant/vagrant/manifests/site.pp:127

  on node puppetmaster.example.com

This tells me that packages do not have composite namevars and that 
titles

do not have uniquification abilities.

A composite namevar for packages could include the package name, 
version, arch

and provider and still work (in the DSL) as usual:

  package {
'pipedream':
  name = 'foo',
  version  = '1.0.0',
  arch = 'noarch'
  provider = 'yum';
  }

would have the title pipedream, the (composite) namevar value
foo:1.0.0:noarch:yum and the properties and parameters as specified 
above.

References to this resource could be of the form

  * Package['pipedream'], Package['foo:1.0.0:noarch:yum']: specific 
instance
  * Package['foo:1.0.0']: equivalent to Package | name == 'foo' and 
version == '1.0.0' |

  * Package['foo']: equivalent to Package | name == 'foo' |

I have no idea whether composite namevars work like this, but it is how 
I think

the problem could be solved.



Regards, David


Trevor

On Sun, Mar 9, 2014 at 6:29 AM, David Schmitt da...@dasz.at [4]
wrote:


On 09.03.2014 03:39, Trevor Vaughan wrote:


In theory a composite namevar could be used if you just specify
the
provider.

For instance, on a Red Hat system:

package { foo: ensure = latest } == namevar == foo:yum

And

package { foo: ensure = latest, provider = gem } == namevar ==
foo:gem

That said, I never could get composite namevars to work this way.
I
always had to have a unique name which ended up in something
silly like
package { foo_rpm:} or package { foo_gem:} which, while it should
work, is absolutely horrible to read.


That was my understanding how composite namevars should have worked
from the beginning. Sadly, this seems too complex or not useful
enough to be actually implemented. It would even help for
multi-arch and multi-versions installations: foo:1.0:i386:yum vs
foo:2.0:amd64:yum.

Regards, David

--
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 [1].
To view this discussion on the web visit



https://groups.google.com/d/msgid/puppet-dev/531C426F.1000903%40dasz.at

[2].

For more options, visit https://groups.google.com/d/optout [3].


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com [5]

-- This account not approved for unencrypted proprietary information
--

 --
 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 [6].
 To view this discussion on the web visit

https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%40mail.gmail.com
[7].
 For more options, visit https://groups.google.com/d/optout [8].


Links:
--
[1] mailto:puppet-dev%2bunsubscr...@googlegroups.com
[2] 
https://groups.google.com/d/msgid/puppet-dev/531C426F.1000903%40dasz.at

[3] https://groups.google.com/d/optout
[4] mailto:da...@dasz.at
[5] mailto:tvaug...@onyxpoint.com
[6] mailto:puppet-dev+unsubscr...@googlegroups.com
[7]

https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%40mail.gmail.com?utm_medium=emailutm_source=footer
[8] https://groups.google.com/d/optout


--
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/ae3fafce9cb7e3521c2437070c291e2e%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] development workflow question

2014-02-13 Thread David Schmitt


On 11.02.2014 22:40, Andy Parker wrote:

On Tue, Feb 11, 2014 at 1:26 AM, David Schmitt da...@dasz.at
mailto:da...@dasz.at wrote:

Hi,


I'm looking into a problem related to PUP-1158. There's a patch that was
merged to master in December. Yet, the ticket is still in Ready for
merge and the patch is not yet in a current puppet release, while
-- from
my limited reading -- it could have easily been incorporated into
any 3.4.x
fixup release.

   * How to proceed with this ticket?
   * Is there any write-up of the new JIRA workflow for externals?


The jira workflow isn't too far off from what it was in Redmine. You can
take a look at
http://docs.puppetlabs.com/community/puppet_projects_workflow.html,
which should explain it all. If it doesn't, just shout and we can try to
fix it up.



That's what I was looking for. puppet development workflow didn't have 
the right google-karma to find that for me.



Thanks everyone else on moving the ticket forwards. 3.5.0 is totally ok 
for me, it's only a warning.



The last question is: how many other open tickets fall through the cracks?


Regards, David



--
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/52FCBC8F.6010603%40dasz.at.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet-dev] development workflow question

2014-02-11 Thread David Schmitt

Hi,


I'm looking into a problem related to PUP-1158. There's a patch that was
merged to master in December. Yet, the ticket is still in Ready for
merge and the patch is not yet in a current puppet release, while -- from
my limited reading -- it could have easily been incorporated into any 3.4.x
fixup release.

  * How to proceed with this ticket?
  * Is there any write-up of the new JIRA workflow for externals?

Regards, David

-- 
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/bd51b7039450e326c5626af901b19407%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet-dev] appeal for advice re: pip provider, multiple packages with same name, etc.

2014-01-22 Thread David Schmitt


On 21.01.2014 19:20, Andy Parker wrote:

I think that what we are hitting here is just a limitation of puppet's
ability to describe systems. What I think is missing is any idea of an
independent container. Within a given container everything needs to be
unique, but between containers you can have duplication. Each container
has certain properties that describe the container and would need to be
accessible from the managed resource while puppet executes. Containers
could be used to model the python virtual environments, different gem
install locations, etc. I think they would also be useful for modeling
different hosts where each host is a container and then you have a
catalog that includes the entire infrastructure.

This is just an idea that I'm throwing out there right now.


Well, it's basically core-support what one would already implement in a 
manifest and workaround as already described with structured resource 
names:


define virtualenv($package) {
package { $name/$package: ensure = installed }
}

Once upon a time there were some patches/talk floating around to parse 
complex titles into parameters and vice versa. That was deemed way too 
complex at that time, but the world seems to have catched up ;-)



Regards, David

--
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/52DF81E5.30503%40dasz.at.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet-dev] issuing web request (REST) from a manifest file

2013-11-14 Thread David Schmitt


On 13.11.2013 17:04, ulrich igor ngouagna kouete wrote:

Hi,

I'm looking for a resource / type that will allow me to issue web
requests from a manifest file. I've heard about the web_request module ,
but seems quite dificult to use (in fact I do not succeed in issuing a
POST request with a JSON body doc).

Any ideas about that?


I needed to get a version number from a REST service just yesterday. My 
solution looks like this:



$current_version = inline_template(% require 'open-uri' %%= open('${version_url}') 
{ |f| f.each_line.to_a.join.strip } %)


That's obviously only a GET request, but it works remarkably well and 
(contrary to Net::HTTP) supports and validates SSL certificates out of 
the box.



Regards, David

--
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/5284873F.6050409%40dasz.at.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet-dev] the webrick server and invalid byte sequence

2013-10-11 Thread David Schmitt


On 11.10.2013 09:28, Sam Sam wrote:

any one using the default webrick server?

I run into invalid byte sequence when running puppet agent -t, is that
normal?


Usually this indicates that the webrick should--but doesn't--run under a 
UTF-8 locale.



Regards, David

--
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] Re: RFI: Windows Reboot Provider - Reboot At End

2013-09-18 Thread David Schmitt


On 2013-09-17 19:47, Rob Reynolds wrote:

Okay, now to introduce my bias into the conversation now that others
have responded.

A - always want to reboot even if other unrelated events fail.

I'd have gone with the property initially. But B can be easily 
implemented by putting the reboot into a cleanup stage, where it'd 
receive the failure notification from main.



So, A for me too. The stage thing might be a nice addition in the docstring.


Regards, David

--
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] extended attributes and puppet… ftw?

2013-03-05 Thread David Schmitt


Hi Wolf,

On 2013-03-02 04:55, Wolf Noble wrote:

it could be a lightweight way for puppet and chef to inform each other
that they 'own' a file….  and what parts of the file they care about,
perms, owner, group, content, to prevent colliding 'config management'


One thing you've missed, which would probably really cool is something 
like a puppet-mtime stamp: When has puppet last managed a file. If it's 
updated everytime puppet runs, it could be a nice auditing mechanism to 
find stuff puppet did manage but does not anymore.



Best Regards, David

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet-dev] agent performance

2013-02-20 Thread David Schmitt

Hi,

meditating over a 13 minute runtime of an agent who's managing 4200
resources, I found this:

-rw-rw 1 root root 1.8M Feb 20 09:45
/var/lib/puppet/state/state.yaml

I seem to remember that yaml serialization can be a problem. Is there a
way to use json for the state.yaml or should I file a bug on that?



Here's the catalog, already in json, so that seems to work out:

-rw-rw 1 root root 6.4M Feb 20 10:06
/var/lib/puppet/client_data/catalog/fqdn.example.com.json


Best Regards, David

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

1 2 3 >

1 - 100 of 247 matches

Mail list logo