from:"Spencer Krum"

Re: [Puppet-dev] Re: Thoughts on Module Namespace Conflicts

2015-08-14 Thread Spencer Krum

I'll resurrect this old thread to give an update. We landed a function
in stdlib to do some of what I discussed in my last post, by inspecting
module metadata directly.

The function:
https://github.com/puppetlabs/puppetlabs-stdlib#load_module_metadata
A blog post I wrote about some possible uses:
http://scienceofficersblog.blogspot.com/2015/08/inspecting-puppet-module-metadata.html

-- 
  Spencer Krum
  n...@spencerkrum.com

On Mon, Feb 23, 2015, at 03:32 PM, Spencer Krum wrote:
 The use case I think for having multiple modules of the same name
 available is quite limited. I don't think anyone would claim best
 practice if they had two apache modules in their modulepath.
 
 I also think there is another component which is versioning. Right now
 there is no system for a profile module to know what version of e.g.
 rabbitmq is installed. This means it just assumes one and fails if the
 rabbitmq class takes different parameters now. One terrible workaround
 for this is for classes to accept a 'rabbitmq_module_version' parameter
 and then switch on it inside the class. This workaround is actually
 used.
 
 So I think as long as we're discussing how to make module owner
 detectable, requireable, whatever, that we should involve versioning as
 well, because bumping minor or major versions of utility modules like
 postgres, mysql, rabbitmq happens a lot.
 
 One case that actually happens where there is a want for two different
 modules by the same name, is when an organization is migrating. An org
 that is moving from example42-apache to puppetlabs-apache isn't gonna
 want to have a flag day where everything is broken. They don't really
 want to play move hosts one by one out of an environment into a testing
 environment then into a 'done' environment. This is where being able to
 have two modules of the same name could be really useful.
 
 Erik proposed allowing modules to specify an interface, then other
 modules could implement that interface. I don't think that is a likely
 outcome. I think when we have two modules that both manage 'apache' the
 only reason one hasn't totally taken over the other is because they have
 different underlying ideas about how to manage apache. I.e. what the
 inputs are and what the scope of the outputs are.
 
 We on the openstack infrastructure team have even gone so far as to fork
 an old version of the apache module to openstackinfra-httpd. This is
 0.0.4 of the pl-apache module and takes wildly different inputs. There
 are three reasons for the fork. One, this module takes a template, fills
 it out, and dumps it in a vhost. Clean and simple. The way we think it
 should be. Two, now that we have forked we can update the codebase,
 clean it up, and fix bugs. Three, with the module now living as 'httpd'
 in our module path, we, or others consuming our infra, can use a modern
 version of the apache module for whatever they need.
 
 
 As a final thought. One way to deal with this problem is to socialize
 the requirement of a new metadata file (yay) called something like
 manifests/properties.pp. This file would have all the data in
 metadata.json. But since it is readable by puppet we could end up with
 code that looks like this in our profiles:
 
 class profile () {
 
case $::apache::properties::author {
   'puppetlabs': {
  // do some apache stuff the puppetlabs way
   }
   'example42': {
  // do some apache stuff the example42 way
   }
   'default': { fail(please stop writing your own apache module) }
 }
 
 }
 
 And the technique for handling multiple versions of the same module is
 basically exactly the same. The cool part of this is that it requires no
 code changes to puppet core. The bad part is we'd have to socialize it
 and thats really hard.
 
 
 -- 
   Spencer Krum
   n...@spencerkrum.com
 
 On Fri, Feb 20, 2015, at 04:34 PM, Henrik Lindberg wrote:
  On 2015-20-02 20:51, Wil Cooley wrote:
   In some ways, this is a lot like environments, but unlike environments,
   which are unique at the node-level, these allow the use of multiple
   module-sets and are scoping for entities at the manifest-level. As I
   understand environments, they can (and probably usually should) be
   relatively isolated from each other; the purpose of namespaced
   module-sets is to allow addressing without isolation. Maybe this is what
   Henrik's last message in this thread is getting at when he says:
  
   I have claimed on many occasions that an environment is just like a
   module (with higher privileges / precedence). The set of available
   modules should be more of a repository kind of thing that the loader
   resolves modules from.
  
  I meant that an environment can be seen as a module. Instead of having a 
  modulepath, it should list all the modules that it requires (those 
  modules in turn can require other modules). When a module is needed it 
  should be resolved against a repository of modules. Such a repository

Re: [Puppet-dev] [announce] beaker-rspec 5.2.0 released

2015-07-15 Thread Spencer Krum

Awesome. Thanks! Been wanting this feature for a while.

--
  Spencer Krum
  n...@spencerkrum.com
 
 
 
On Wed, Jul 15, 2015, at 02:01 PM, Alice Nodelman wrote:
 In this release:
  
 - Add environment variable to expose --no-color
   * use BEAKER_color or RS_COLOR = no to disable coloring log output
 Details here:
 https://github.com/puppetlabs/beaker-rspec/blob/master/HISTORY.md#LATEST
 High Fives!
 alice.
 


 -- 
 
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/188b297e-6e07-4959-85fd-298e7db7ee85%40googlegroups.com[1].
 
For more options, visit https://groups.google.com/d/optout.
 


Links:

  1. 
https://groups.google.com/d/msgid/puppet-dev/188b297e-6e07-4959-85fd-298e7db7ee85%40googlegroups.com?utm_medium=emailutm_source=footer

-- 
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/1436996397.1455199.324797985.23CCFE86%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Validation Resources

2015-05-20 Thread Spencer Krum

Thanks everyone for your feedback. It sounds like this is a popular
idea, and one that leads into further discussion.

I've created https://github.com/puppet-community/puppet-healthcheck and
asked spredzy to submit the PR against that repo.

Cheers,
Spencer

--
Spencer Krum
n...@spencerkrum.com

On Fri, May 15, 2015, at 03:52 PM, Luke Kanies wrote:
On May 14, 2015, at 12:11 PM, Spencer Krum n...@spencerkrum.com wrote:

Hi Folks,

There is currently a PR against stdlib that I am writing to you today
about: https://github.com/puppetlabs/puppetlabs-stdlib/pull/444
Thanks to Spredzy for making this PR.

This is tracked in jira:
https://tickets.puppetlabs.com/browse/MODULES-1982

This pattern has poked up a few different places. As the PR says, it has
shown up in the monogodb module and the puppetdb module. I know that
Michael Chapman added something like this to his OpenStack things and
Dan Bode as well.

At the modules triage today we had the following reactions (please reply
if there is something you said I didn't get):

* This is a new pattern
* Having it in stdlib means we can't iterate on it quickly
* This is a library thing, and should be a library
* Once standardized, puppetdb and other modules could be retrofitted to
use it
* This will probably change frequently as people use it and explore what
it should/can do

We had the idea that rather than landing this in puppet-stdlib, that we
could create a module in puppet-community to hold this and other
validation/health check resources.

We had some ideas on the name:

puppet-healthcheck
puppet-validation
puppet-external_validate.

It's worth noting that these are primitives for building multi-node
orchestration with Puppet.

What do you think? Do you use these patterns? Would you? What would you
want from your library?

(Sorry, coming late to the thread.)

I think this is a great idea.

I built something similar a long time ago:

https://github.com/puppetlabs/puppetlabs-remote_resource/blob/master/ext/example.pp

I agree it should be independent, at least for now, to support faster
evolution and because I like small things. :)

However…

This is something we’re working on a ton internally, for related but
different reasons. Nothing is in a state that’s worth sharing,
unfortunately, because this is just one part of a much larger project and
we can’t easily share any of it until we can share all of it (because
it’s very confusing in its current state, among other reasons).

Basically, we want to build a special kind of resource for exactly this.
All resources of this special type would share some values, like interval
and timeout, and then each resource type would provide the parameters for
things like IP address, port, etc.

We want to go quite a bit past just checking IP and port, though.

I want a base provider that can just check network status, but why not a
provider that can check whether a database is all set up, and a user can
connect with a specific password?

Or why not something that validates that a filesystem is available? No
network information, just validate that a file is present, or something
similar. These often take a while to actually work.

Or even more, why not confirm that a configuration file is valid?
Wouldn’t you love something that would roll back the sudoers file if you
managed to deploy a broken one?

In other words, this should be a generic framework, with generic support
from Puppet, and we should provide as much power to the framework as
possible.

We’re really only focused on the simplest form of health checks at this
point, but because we’re explicitly expecting to make some changes to
core Puppet to make some of it work, we likely won’t be able to make the
whole thing external.

We’re basically at the “plan to build” phase right now, without full
designs in place.

David Lutterkort is one of the eng leads, and Ryan Coleman is the product
manager.

And I’m off to China for a week in 12 hours, so I’ll be off the grid for
the next week, and thus can’t elaborate. :/

And, in regards to Trevor’s rant, and pointing to the old ticket, yeah,
it’s exactly that stuff (plus a lot more) that’s led us to this. We’re
just finally getting to invest in it. :)

—
http://puppetlabs.com/ | http://about.me/lak | @puppetmasterd

--
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/651C9A29-8133-4E1A-B14E-8493B203E091%40puppetlabs.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

[Puppet-dev] Validation Resources

2015-05-14 Thread Spencer Krum

Hi Folks,

There is currently a PR against stdlib that I am writing to you today
about: https://github.com/puppetlabs/puppetlabs-stdlib/pull/444
Thanks to Spredzy for making this PR.

This is tracked in jira:
https://tickets.puppetlabs.com/browse/MODULES-1982

At the modules triage today we had the following reactions (please reply
if there is something you said I didn't get):

We had the idea that rather than landing this in puppet-stdlib, that we
could create a module in puppet-community to hold this and other
validation/health check resources.

We had some ideas on the name:

puppet-healthcheck
puppet-validation
puppet-external_validate.

It's worth noting that these are primitives for building multi-node
orchestration with Puppet.

What do you think? Do you use these patterns? Would you? What would you
want from your library?

Thanks,
Spencer

--
Spencer Krum
n...@spencerkrum.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/1431630674.2625129.268922745.5AA0382C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Validation Resources

2015-05-14 Thread Spencer Krum

Trevor,

I agree that if you take it to its logical conclusion you end up with
semaphores stored in consul and a handful of Puppet resources to
interact with them. Dan Bode presented on exactly this (and what doesn't
work well about it) at the PDX Puppet Users group last month.

I think though that from a practical standpoint, these resources as
written have value. Simply waiting for some java process to start before
you do follow-on actions is a common task. And looking to the future I'd
like to see them live in their own module so we can evolve them without
symver constraints.

--
Spencer Krum n...@spencerkrum.com

On Thu, May 14, 2015, at 12:29 PM, Trevor Vaughan wrote:
Ugh, sorry all, didn't mean to make that so rant-ish.

Anyway, it would seem that you would not want to hold up a catalog
compilation or application for this. Instead, you would want to
register the check with a service that could drop a queriable entity
that could be used by Puppet for making decisions about the
compilation and/or application of the catalog.

PuppetDB may be the ideal place to host this but it could also be a
stand-alone, authenticated, service.

Obviously, nodes should only obtain their own data unless explicitly
shared between a node group.

In terms of naming, I would probably call it network_service_status or
some such.

Thanks,

Trevor

On Thu, May 14, 2015 at 3:24 PM, Trevor Vaughan
tvaug...@onyxpoint.com wrote:
I'd like to counter this limited use case with my rant about
semaphores from five years ago:
http://comments.gmane.org/gmane.comp.sysutils.puppet.devel/13039.

Followed by the conversation from two years ago.
https://projects.puppetlabs.com/issues/16187

What you want is cross-node synchronization and synchronization
storage state.

You can sort of do this with exported resources, but it's VERY
clumsy.

I know that it's a long shot, but I figure that I'll resurrect it as
appropriate every couple of years ;-).

Other than that, why not call it 'haproxy'.

Trevor

On Thu, May 14, 2015 at 3:11 PM, Spencer Krum
n...@spencerkrum.com wrote:
Hi Folks,

There is currently a PR against stdlib that I am writing to you today

about: https://github.com/puppetlabs/puppetlabs-stdlib/pull/444

Thanks to Spredzy for making this PR.

This is tracked in jira:
https://tickets.puppetlabs.com/browse/MODULES-1982

This pattern has poked up a few different places. As the PR says, it has

shown up in the monogodb module and the puppetdb module. I know that

Michael Chapman added something like this to his OpenStack things and

Dan Bode as well.

At the modules triage today we had the following reactions (please reply

if there is something you said I didn't get):

* This is a new pattern

* Having it in stdlib means we can't iterate on it quickly

* This is a library thing, and should be a library

* Once standardized, puppetdb and other modules could be retrofitted to

use it

* This will probably change frequently as people use it and explore what

it should/can do

We had the idea that rather than landing this in puppet-stdlib, that we

could create a module in puppet-community to hold this and other

validation/health check resources.

We had some ideas on the name:

puppet-healthcheck

puppet-validation

puppet-external_validate.

It's worth noting that these are primitives for building multi-node

orchestration with Puppet.

What do you think? Do you use these patterns? Would you? What would you

want from your library?

Thanks,

Spencer

Spencer Krum
n...@spencerkrum.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[1].

To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/1431630674.2625129.268922745.5AA0382C%40webmail.messagingengine.com.

For more options, visit https://groups.google.com/d/optout.

Trevor Vaughan Vice President, Onyx Point, Inc
(410) 541-6699[2] tvaug...@onyxpoint.com

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

--
Trevor Vaughan Vice President, Onyx Point, Inc
(410) 541-6699 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.

To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXvKm6u%2BbJoz2jUwttsiUBKhLLWphvGPzOkG3--j%3DK9Pw%40mail.gmail.com[3].

For more options, visit https://groups.google.com/d/optout.

Links:

1. mailto:puppet-dev%2bunsubscr...@googlegroups.com
2. tel:%28410%29%20541-6699
3.
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXvKm6u

Re: [Puppet-dev] Re: Thoughts on Module Namespace Conflicts

2015-02-23 Thread Spencer Krum

The use case I think for having multiple modules of the same name
available is quite limited. I don't think anyone would claim best
practice if they had two apache modules in their modulepath.

I also think there is another component which is versioning. Right now
there is no system for a profile module to know what version of e.g.
rabbitmq is installed. This means it just assumes one and fails if the
rabbitmq class takes different parameters now. One terrible workaround
for this is for classes to accept a 'rabbitmq_module_version' parameter
and then switch on it inside the class. This workaround is actually
used.

So I think as long as we're discussing how to make module owner
detectable, requireable, whatever, that we should involve versioning as
well, because bumping minor or major versions of utility modules like
postgres, mysql, rabbitmq happens a lot.

One case that actually happens where there is a want for two different
modules by the same name, is when an organization is migrating. An org
that is moving from example42-apache to puppetlabs-apache isn't gonna
want to have a flag day where everything is broken. They don't really
want to play move hosts one by one out of an environment into a testing
environment then into a 'done' environment. This is where being able to
have two modules of the same name could be really useful.

Erik proposed allowing modules to specify an interface, then other
modules could implement that interface. I don't think that is a likely
outcome. I think when we have two modules that both manage 'apache' the
only reason one hasn't totally taken over the other is because they have
different underlying ideas about how to manage apache. I.e. what the
inputs are and what the scope of the outputs are.

We on the openstack infrastructure team have even gone so far as to fork
an old version of the apache module to openstackinfra-httpd. This is
0.0.4 of the pl-apache module and takes wildly different inputs. There
are three reasons for the fork. One, this module takes a template, fills
it out, and dumps it in a vhost. Clean and simple. The way we think it
should be. Two, now that we have forked we can update the codebase,
clean it up, and fix bugs. Three, with the module now living as 'httpd'
in our module path, we, or others consuming our infra, can use a modern
version of the apache module for whatever they need.


As a final thought. One way to deal with this problem is to socialize
the requirement of a new metadata file (yay) called something like
manifests/properties.pp. This file would have all the data in
metadata.json. But since it is readable by puppet we could end up with
code that looks like this in our profiles:

class profile () {

   case $::apache::properties::author {
  'puppetlabs': {
 // do some apache stuff the puppetlabs way
  }
  'example42': {
 // do some apache stuff the example42 way
  }
  'default': { fail(please stop writing your own apache module) }
}

}

And the technique for handling multiple versions of the same module is
basically exactly the same. The cool part of this is that it requires no
code changes to puppet core. The bad part is we'd have to socialize it
and thats really hard.


-- 
  Spencer Krum
  n...@spencerkrum.com

On Fri, Feb 20, 2015, at 04:34 PM, Henrik Lindberg wrote:
 On 2015-20-02 20:51, Wil Cooley wrote:
  In some ways, this is a lot like environments, but unlike environments,
  which are unique at the node-level, these allow the use of multiple
  module-sets and are scoping for entities at the manifest-level. As I
  understand environments, they can (and probably usually should) be
  relatively isolated from each other; the purpose of namespaced
  module-sets is to allow addressing without isolation. Maybe this is what
  Henrik's last message in this thread is getting at when he says:
 
  I have claimed on many occasions that an environment is just like a
  module (with higher privileges / precedence). The set of available
  modules should be more of a repository kind of thing that the loader
  resolves modules from.
 
 I meant that an environment can be seen as a module. Instead of having a 
 modulepath, it should list all the modules that it requires (those 
 modules in turn can require other modules). When a module is needed it 
 should be resolved against a repository of modules. Such a repository 
 could be implemented many ways; one being that it is just the modules 
 now on the modulepath.
 
 The main difference is that the resolution from name to actual module is 
 now free from implementation concerns.
 
 Currently the dependencies that are expressed are between the containers 
 of logic (the module depends on another specific module with a specific 
 implementations e.g. puppetlabs/stdlib). This is simple but not very 
 flexible. It would be far better if the requirements were established 
 based on what is actually required from that module - say that it needs

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

2014-12-20 Thread Spencer Krum

This is awesome. I've recommended it to my old work. This is absolutely
necessary when automating some of the hairy enterprise apps I've worked
with.

--
Spencer Krum
n...@spencerkrum.com

On Sat, Dec 20, 2014, at 10:00 AM, David Schmitt wrote:
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/1419108825.1373821.205262217.70C63FFE%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Beaker-extensions

2014-11-28 Thread Spencer Krum

I think this is a good idea. It is a bit concerning that Alice doesn't
think there is a good way to add extensions to beaker right now, maybe
development time at #puppethack could be spent shoring that up. I'm +1
on this and would add my limited experience to the maintainer hat pool.

--
Spencer Krum n...@spencerkrum.com

On Fri, Nov 28, 2014, at 06:44 AM, Peter M Souter wrote:
Hi All!

So, Beaker is awesome. But there are some features that are
nice-to-haves that aren't needed for Puppetlabs themselves:

https://github.com/puppetlabs/beaker/issues/512
https://github.com/puppetlabs/beaker/issues/499

So, I thought about having these as extensions in a separate gem,
that if someone wants to run tests in their module for FreeBSD, or
run it against new providers such as DigitalOcean, Linode etc. they
can add them.

When this gets into a workable state, I'd like to move it to
https://github.com/puppet-community :)

I'm not a Ruby whiz, but this is what I've come up with so far:

https://github.com/petems/beaker-extensions

I was planning on working on this for #puppethack, any help is
appreciated! :D

Thanks

Regards

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/8c740faf-c45f-41fa-91a1-8d6f3dd722d7%40googlegroups.com[1].

For more options, visit https://groups.google.com/d/optout.

Links:

1.
https://groups.google.com/d/msgid/puppet-dev/8c740faf-c45f-41fa-91a1-8d6f3dd722d7%40googlegroups.com?utm_medium=emailutm_source=footer

--
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/1417201472.1207958.196500969.3A909F6B%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-11-20 Thread Spencer Krum

There is talk of splitting out some of the types (nagios and zfs most
notably) into modules, then packaging those modules. Are we thinking those
module packages would be in this AIO? Is that still on target for Puppet 4?

On Thu, Nov 20, 2014 at 11:56 AM, Leonardo Rodrigues de Mello
l...@lmello.eu.org wrote:

Would the gems still be released ? I am concerned because we use the
mcollective client gem in a web application and I also use multiple puppet
and facter gems in rbenv for testing.

Best
Em 19/11/2014 17:36, Eric Sorenson eric.soren...@puppetlabs.com
escreveu:

On Nov 19, 2014, at 11:20 AM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:

Hmm...Facter and MCollective not being independently upgradable isn't
super exciting.

If any one of the main constituent projects having a release would cause
a new AIO to come out, is that the right cycle?

(Do you currently always track the latest package of the Puppet-related
projects you use?)

--eric0

--
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/472E836F-A255-4EA7-B98E-D71DFCC73E83%40puppetlabs.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/CAM%3D8oNJ0FvT03Y-ydYPPdzCagqWuQA3v10gj1%3DRcZhKA_1%2BdGQ%40mail.gmail.com
https://groups.google.com/d/msgid/puppet-dev/CAM%3D8oNJ0FvT03Y-ydYPPdzCagqWuQA3v10gj1%3DRcZhKA_1%2BdGQ%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

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

Re: [Puppet-dev] Re: zpool mirror and raidz virtual devices

2014-11-13 Thread Spencer Krum

Josh, What version of solaris were you testing this on? Its possible that
the zpool command has changed behavior more recently than Puppet 3.0, thus
making it look like this has been broken that long.

Furthermore I'm not sure if the different zfs implementations all use the
exact same command structure at this point.

With Geoffery stepping up to take ownership of this stuff, and some
consensus around spitting out the zfs stuff, I think we should split out
the zfs/zpool types and providers into puppet-community/puppet-module-zfs
and give Geoffery commit access.

We should do this with at least a ping to the FreeBSD folks in case they
want to get involved as well.

Thanks,
Spencer

On Thu, Nov 13, 2014 at 7:35 PM, Geoffrey Gardella garde...@gmail.com
wrote:

Hi Josh!
I am with Oracle and have just been assigned to work on Puppet in Solaris.
I am just getting oriented, but this looks like something we should be
working on. Is this functionality being covered elsewhere? If not, I can
open an internal ticket to get this covered.

So far, we aren't even pushing our changes back upstream, so fixing that
that is my first order of business.

Cheers,
Geoffrey

On Monday, November 10, 2014 11:06:51 PM UTC-8, Josh Cooper wrote:

There looks to be a bug in the current zpool provider, where if you have
a manifest like:

mirror = [disk1 disk2, disk3 disk4],

Puppet will execute:

zpool create data mirror disk1 disk2 disk3 disk4

Instead of:

zpool create data mirror disk1 disk2 mirror disk3 disk4

Adam put together a PR at https://github.com/
Incognito1992/puppet/compare/ticket/master/PUP-3388-zpool-mirrors, but
while researching it, I think this is really a regression due to
http://projects.puppetlabs.com/issues/16157, commit https://github.com/
puppetlabs/puppet/commit/4a6853e1de083842362dc30d08429b029f64, first
introduced in Puppet 3.0.

The Oracle docs[1] seem to support that Puppet is now doing the wrong
thing:

Virtual devices are specified one at a time on the command line,
separated by whitespace. The keywords “mirror” and “raidz” are used to
distinguish where a group ends and another begins. For example, the
following creates two root vdevs, each a mirror of two disks:

# zpool create mypool mirror c0t0d0 c0t1d0 mirror c1t0d0 c1t1d0

This seems pretty straightforward, but I wanted to raise the issue here,
because I am not a Solaris expert, and it's been broken for awhile without
anyone noticing... I've submitted a PR at https://github.com/
puppetlabs/puppet/pull/3299, comments welcome.

Josh

[1] https://docs.oracle.com/cd/E23824_01/html/821-1462/zpool-1m.html

--
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/7dd557f6-cac1-4d99-a9c5-89dfc6158b82%40googlegroups.com
https://groups.google.com/d/msgid/puppet-dev/7dd557f6-cac1-4d99-a9c5-89dfc6158b82%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

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

Re: [Puppet-dev] zpool mirror and raidz virtual devices

2014-11-11 Thread Spencer Krum

I'm as big a ZFS fanboy as anyone, but I've never used Puppet to manage a
zpool, and I never will. If this has been broken for a long time, then my
situation is not atypical.

Maybe this is a good time to split the zpool stuff out of Puppet core and
into a module?

I can see instances where I would use puppet to manage zfs filesystems,
fwiw.

On Tue, Nov 11, 2014 at 8:06 AM, Josh Cooper j...@puppetlabs.com wrote:

There looks to be a bug in the current zpool provider, where if you have a
manifest like:

mirror = [disk1 disk2, disk3 disk4],

Puppet will execute:

zpool create data mirror disk1 disk2 disk3 disk4

Instead of:

zpool create data mirror disk1 disk2 mirror disk3 disk4

Adam put together a PR at https://github.com/Incognito1992/puppet/compare/
ticket/master/PUP-3388-zpool-mirrors, but while researching it, I think
this is really a regression due to http://projects.puppetlabs.
com/issues/16157, commit https://github.com/puppetlabs/puppet/commit/
4a6853e1de083842362dc30d08429b029f64, first introduced in Puppet 3.0.

The Oracle docs[1] seem to support that Puppet is now doing the wrong
thing:

Virtual devices are specified one at a time on the command line, separated
by whitespace. The keywords “mirror” and “raidz” are used to distinguish
where a group ends and another begins. For example, the following creates
two root vdevs, each a mirror of two disks:

# zpool create mypool mirror c0t0d0 c0t1d0 mirror c1t0d0 c1t1d0

Josh

[1] https://docs.oracle.com/cd/E23824_01/html/821-1462/zpool-1m.html

--
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/f7237160-0528-47ee-8ba3-335fbd64ed9a%40googlegroups.com
https://groups.google.com/d/msgid/puppet-dev/f7237160-0528-47ee-8ba3-335fbd64ed9a%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

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

Re: [Puppet-dev] Re: Leaving Puppet Labs

2014-11-06 Thread Spencer Krum

Thank you Andy. You will be missed. You will bring great value to your next
endeavor.

As daenny said, don't be a stranger.

On Thu, Nov 6, 2014 at 9:26 AM, Daniele Sluijters 
daniele.sluijt...@gmail.com wrote:

 No. I do not accept.

 :(

 Thank you, for so much, for your code, your contributions and your
 patience. It's been a privilege.

 Best of luck and don't be a stranger!

 --
 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/673f7a1c-2d6b-45cb-93b4-86848509686c%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-dev/673f7a1c-2d6b-45cb-93b4-86848509686c%40googlegroups.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
Spencer Krum
(619)-980-7820

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

Re: [Puppet-dev] Switching from YAML and PSON to JSON

2014-10-23 Thread Spencer Krum

-dev/CANhgQXtegN-WVmJfcb_kQekWg25iVKC1w4P7tJ_rB%2BqzQY3owg%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
Spencer Krum
(619)-980-7820

-- 
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/CADt6FWPS_q4s%2B3SVs%3DzDaOv0iaFg7KD8NZ1MOeyB7R3-Q6iX5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Abusing PuppetDB

2014-09-15 Thread Spencer Krum

Can you flesh out a bit more what you are looking for? If I'm reading
between the lines correctly you may be better served with a database backed
hiera backend.
On Sep 15, 2014 9:04 AM, Trevor Vaughan tvaug...@onyxpoint.com wrote:

I like the word 'formally'. Any informal material that you know of?

If I can get what I want working, I'll push upstream, but it's always
easier to start from a base.

Thanks,

Trevor

On Mon, Sep 15, 2014 at 10:54 AM, Ken Barber k...@puppetlabs.com wrote:

I'm wondering if anyone has a relatively straightforward way to allow a
group of Puppet Masters to access a shared data table in PuppetDB to
which
they can read and write named JSON objects.

No other hosts should be able to access the data.

Nothing like this has been provided formally today.

ken.

--
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/CAE4bNTk9ctc8%3DO%2BuYXmTRJUP9SMFE685VMJtrTR%2BKA-LoLCDZA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVBW07jYwcTj5TzS3swdgHE97EK_N3Nd2hjy93PLMwpkg%40mail.gmail.com
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVBW07jYwcTj5TzS3swdgHE97EK_N3Nd2hjy93PLMwpkg%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/CADt6FWPKjHFdiZXQHmcbYeGCkHuM4PUgQLEyJ_DyKHnXsY8hiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Statistics for Modules

2014-09-10 Thread Spencer Krum

Yes integration would have to be opt-in. I'm sure the maintainers of those
tools would want it that way anyways. And everything would have to respect
the http_proxy variable, everyone's favorite variable in corporate settings.

On Wed, Sep 10, 2014 at 5:58 AM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:

If anyone does tool integration PLEASE make it opt-in.

It's always fun trying to explain why your tools are pounding on the
inside of a corporate firewall.

Trevor

On Wed, Sep 10, 2014 at 1:40 AM, Gareth Rushgrove
gar...@morethanseven.net wrote:

On 7 September 2014 15:57, Spencer Krum krum.spen...@gmail.com wrote:
Hi Puppet-dev,

I've been working, with a lot of help from some others, on a new
project at
http://puppet-analytics.org. It is very much in the
experimental/development
phase and I'm looking for feedback and help.

The goal of this project is to enable module authors and users greater
visibility into module use. The architecture is modeled after Debian's
popularity contest, where a program on the debian system reports to a
central server about package use. This means that Puppet users can
submit(through a json/http endpoint) 'hey I've deployed this version of
stdlib!'. After a bunch of users have been reporting for a while, module
maintainers can see the trends, identify which versions of the modules
are
being used, etc. Similarly users can see which modules are the most
popular,
which versions of those modules are the most popular, etc.

There is an arbitrary tagging system built in that allows users to
report
that the deploy is being performed by their ci infrastructure, by a
developer doing testing, or by an operator pushing code to production.
This
allows people viewing the data to see the 'true' numbers, unpolluted by
ci
systems or runaway webcrawlers.

Reporting can be done with curl, or with a script. Right now there is a
script and example curl to report to puppet analytics at:
https://github.com/nibalizer/puppet-analytics-client. I think
everyone's
infrastructure looks a little different, so writing a generic tool to
report
to PA would be pretty hard. I'd like puppet-analytics-client to become a
place to put scripts and tools to hit PA.

I'm interested in your thoughts an opinions. Especially around the
opt-in
architecture. Would you be willing to report to PA? Do you think we
would
ever be able to get enough people reporting that the data would be
significant? All the code is open source on github
(https://github.com/nibalizer/puppet-analytics). The website is hosted
on
digital ocean. I also have the mental model that people would report
after
every code change to their Puppet infrastructure, i.e. in the
post-commit
hook if using dynamic environments. Is this a model you agree with? Do
you
have a different idea?

We have had a lot of conversations, on this list, and in person, around
'what are people doing with puppet?' I think a tool like this could
really
help us figure out which modules are being used the most often.

Please note that PA is not nearly done yet. Much of the empty space I
expect
will be filled in with cool visualizations of the data. It is liable to
break at any time, especially with actual users. One of the cool
features
that is currently in PR is the ability to have shields.io downloads
tags
come from PA and show up in the ReadMe's of our modules.

I mentioned last night at the Portland Puppet User Group that I think
from a module developers point of view this is really cool.

A couple of things I said which may be worth repeating are that rapid
integration with some of the dependency tools could net lots of data
quickly, for instance:

* librarian-puppet
* r10k
* geppetto
* vagrant

Probably some others I've forgotten.

Gareth

Thanks everybody,
Spencer

--
Spencer Krum
(619)-980-7820

https://groups.google.com/d/msgid/puppet-dev/CADt6FWPoK7N6pwPj4h6_84p-6WEwtz3N6zJbuJniRkHaMi9HBA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.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/CAFi_6yKyY03L-NMdo2qy%3DeNSZYQPWem8bJUeeoBU3_yJLfpkmQ%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx

Re: [Puppet-dev] Statistics for Modules

2014-09-08 Thread Spencer Krum

Thanks for the positive feedback Andy!


I'm wondering if there would be a way of saying all of these installations
 are for the same 'site'. That would remove a module looking popular simply
 because it is installed a lot, but only by two or three groups. Maybe that
 information is valuable, maybe not...I'm not sure yet.


One of the common practices when building a system such as this is keeping
the people who send you data anonymous. That makes filtering on user hard.
We could potentially deal with that in two ways I can think of. We could
allow users to set a anonymous=false flag in their json blob they deliver,
or we could hash the source ip address and keep that around.

I think the way I intended for it to be used was for users doing CI was to
report that CI in the purpose field. That way we could see total
deployments, but also per-usage deployments. I'm not sure the users would
be willing to differentiate how they run a script between production and CI
though, since the goal of CI is to test it as close to prod as you can.



I'm personally a little cautious about making a deploy process depend on
 external services, but this could be fired off as a background job and it
 doesn't really matter too much if it works or not.


I agree that it is a big pill to swallow.  This will likely change, but
right now every deploy must be reported in a single curl request, no bulk
updates. It is also not possible to 'back-fill' data. So deploys are
recorded when they are submitted to puppet-analytics. I could see deploys
for the day being written to a file or database on the users systems, then
a nightly job running to fill in the days deploys on puppet-analytics, but
it would require some changes to the code.

I weighed the balance of allowing arbitrary date insertion. I'm happy to be
convinced otherwise but I think the problems of figuring out when a deploy
occurred when reported by a global system with timezones and all that is
very hard to get right.

Thanks again,
Spencer



On Mon, Sep 8, 2014 at 11:21 AM, Andy Parker a...@puppetlabs.com wrote:

 On Sun, Sep 7, 2014 at 3:57 PM, Spencer Krum krum.spen...@gmail.com
 wrote:

 Hi Puppet-dev,

 I've been working, with a lot of help from some others, on a new project
 at http://puppet-analytics.org. It is very much in the
 experimental/development phase and I'm looking for feedback and help.

 The goal of this project is to enable module authors and users greater
 visibility into module use. The architecture is modeled after Debian's
 popularity contest, where a program on the debian system reports to a
 central server about package use. This means that Puppet users can
 submit(through a json/http endpoint) 'hey I've deployed this version of
 stdlib!'. After a bunch of users have been reporting for a while, module
 maintainers can see the trends, identify which versions of the modules are
 being used, etc. Similarly users can see which modules are the most
 popular, which versions of those modules are the most popular, etc.


 This all looks awesome!


 There is an arbitrary tagging system built in that allows users to report
 that the deploy is being performed by their ci infrastructure, by a
 developer doing testing, or by an operator pushing code to production. This
 allows people viewing the data to see the 'true' numbers, unpolluted by ci
 systems or runaway webcrawlers.


 I'm wondering if there would be a way of saying all of these
 installations are for the same 'site'. That would remove a module looking
 popular simply because it is installed a lot, but only by two or three
 groups. Maybe that information is valuable, maybe not...I'm not sure yet.


 Reporting can be done with curl, or with a script. Right now there is a
 script and example curl to report to puppet analytics at:
 https://github.com/nibalizer/puppet-analytics-client. I think everyone's
 infrastructure looks a little different, so writing a generic tool to
 report to PA would be pretty hard. I'd like puppet-analytics-client to
 become a place to put scripts and tools to hit PA.

 I'm interested in your thoughts an opinions. Especially around the opt-in
 architecture. Would you be willing to report to PA? Do you think we would
 ever be able to get enough people reporting that the data would be
 significant? All the code is open source on github (
 https://github.com/nibalizer/puppet-analytics). The website is hosted on
 digital ocean. I also have the mental model that people would report after
 every code change to their Puppet infrastructure, i.e. in the post-commit
 hook if using dynamic environments. Is this a model you agree with? Do you
 have a different idea?


 I think that is a great thing to shoot for. I'm personally a little
 cautious about making a deploy process depend on external services, but
 this could be fired off as a background job and it doesn't really matter
 too much if it works or not.


 We have had a lot of conversations, on this list, and in person, around

[Puppet-dev] Statistics for Modules

2014-09-07 Thread Spencer Krum

Hi Puppet-dev,

I've been working, with a lot of help from some others, on a new project at
http://puppet-analytics.org. It is very much in the
experimental/development phase and I'm looking for feedback and help.

The goal of this project is to enable module authors and users greater
visibility into module use. The architecture is modeled after Debian's
popularity contest, where a program on the debian system reports to a
central server about package use. This means that Puppet users can
submit(through a json/http endpoint) 'hey I've deployed this version of
stdlib!'. After a bunch of users have been reporting for a while, module
maintainers can see the trends, identify which versions of the modules are
being used, etc. Similarly users can see which modules are the most
popular, which versions of those modules are the most popular, etc.

There is an arbitrary tagging system built in that allows users to report
that the deploy is being performed by their ci infrastructure, by a
developer doing testing, or by an operator pushing code to production. This
allows people viewing the data to see the 'true' numbers, unpolluted by ci
systems or runaway webcrawlers.

Reporting can be done with curl, or with a script. Right now there is a
script and example curl to report to puppet analytics at:
https://github.com/nibalizer/puppet-analytics-client. I think everyone's
infrastructure looks a little different, so writing a generic tool to
report to PA would be pretty hard. I'd like puppet-analytics-client to
become a place to put scripts and tools to hit PA.

I'm interested in your thoughts an opinions. Especially around the opt-in
architecture. Would you be willing to report to PA? Do you think we would
ever be able to get enough people reporting that the data would be
significant? All the code is open source on github (
https://github.com/nibalizer/puppet-analytics). The website is hosted on
digital ocean. I also have the mental model that people would report after
every code change to their Puppet infrastructure, i.e. in the post-commit
hook if using dynamic environments. Is this a model you agree with? Do you
have a different idea?

We have had a lot of conversations, on this list, and in person, around
'what are people doing with puppet?' I think a tool like this could really
help us figure out which modules are being used the most often.

Please note that PA is not nearly done yet. Much of the empty space I
expect will be filled in with cool visualizations of the data. It is liable
to break at any time, especially with actual users. One of the cool
features that is currently in PR is the ability to have shields.io
downloads tags come from PA and show up in the ReadMe's of our modules.

Thanks everybody,
Spencer

--
Spencer Krum
(619)-980-7820

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

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

2014-08-12 Thread Spencer Krum

1) I really don't want to see variable expansion in expressions that
resolve to the names of types. This will be misused, it will make code
unreadable. Please leave it out. Sets of parameters only make sense to
distinct types anyways, if two types really do accept all the same
parameters, then the RAL should be leveraged and different providers
written.

It is already used (via create_resources), and people want it to support
integration use cases between more tightly coupled modules.

The fact that only four modules use it is, to me, exactly validation that
it’s a rare enough use case that it should be left to things like functions.

The language should be optimized for the most common use cases, not the
complete list of them.

I think Luke has nailed it. Only in the rarest circumstances will this be
used to make the code better, and thats not something that should be
optimized for.

What do you think about the proposal to precede the meta parameter name
with @, since we have issues with reserving yet another name (all good
names seems to be in use somewhere already).

We proposed @attributes, so by analogy, it would be @params_hash, or
equivalent using the word you preferred.

I think my disagreement on this is that I consider adding @something to the
type syntax to be a bigger crime than reserving a word. If it ends up
googleale, I'm okay with it.

(you probably wanted $params = $defaults + $attributes)

Yes, I did. Thanks for taking the time to figure out what I meant, because
what I said was garbage. Is $hash1 + $hash2 something that works? I would
expect merge behavior there, is that what happens?

Thanks,
Spencer

On Tue, Aug 12, 2014 at 11:48 AM, Luke Kanies l...@puppetlabs.com wrote:

On Aug 12, 2014, at 10:02 AM, Andy Parker a...@puppetlabs.com wrote:

On Mon, Aug 11, 2014 at 8:54 PM, Spencer Krum krum.spen...@gmail.com
wrote:

I hadn't looked for this information before because I just assumed that if
it is possible it is being used :) However, I just did a quick trawl
through the forge and the following modules use variables for the type in
create_resources:

* vstone-apache
* puppetlabs-swift
* jaydub-resource_factory
* eNovance-cloud

There is also jakeb-system and erwbgy-system which seem to be copies of
one another. They don't use create_resources, but seem to have forked it
into a new function called system_create_resources which is then used with
a variable type. It isn't clear to me what is different about the forked
function.

Looking at the examples, usage of interpolating the type name is usually
done in order to have different defined types for different situations, but
shield the user of the module from needing to know about them. This seems
like a very reasonable use.

The fact that only four modules use it is, to me, exactly validation that
it’s a rare enough use case that it should be left to things like functions.

The language should be optimized for the most common use cases, not the
complete list of them.

[…]

--
http://puppetlabs.com/ | http://about.me/lak | @puppetmasterd

--
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/BAF188D7-BF00-49AD-8F54-7E5FC4F971ED%40puppetlabs.com
https://groups.google.com/d/msgid/puppet-dev/BAF188D7-BF00-49AD-8F54-7E5FC4F971ED%40puppetlabs.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

--
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/CADt6FWMj_2cdSB-%3DywMHU6vT8m%3DXNF%2BAX8-wXnc2iQJtdx9hZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-08-11 Thread Spencer Krum

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 ;-)

I just did a quick search through the modules on the forge and the
follow modules all use a parameter called 'attributes':

* sensu-sensu-1.0.0
* deric-mesos-0.2.0 through 0.4.1
* CERNOps-activemq-0.0.1

This is the problem with trying to take a word (and the same problem
that the meta parameters encounter), once that name is taken globally,
then nobody else can use it, no matter how good their intentions :/

In different news, but related, Henrik has started working with the UX
team to come up with something that we can put in front of people to get
a more definitive answer. However, they are saying that they won't be
able to get any results until the end of August. We need to come up with
an interim solution and then probably make some changes in a bugfix
release.

And we added yet another option, a compromise of using an operator and a
name.

file { 'title': @attributes = $hash }

The @ only combines with the exact word attributes. This makes it
googlable, descriptive, does not require name to be reserved, and it
meets the technical requirements (it can be parsed etc).

- henrik

Visit my Blog Puppet on the Edge
http://puppet-on-the-edge.blogspot.se/

For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

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

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

2014-08-06 Thread Spencer Krum

: * = $attributes; }
 file { $title: = $attributes; }
 file { $title: ($attributes); }
 file { $title: attribute_defaults = $attributes; }
 file { $title: attribute_hash = $attributes; }


 Using attribute_hash is certainly a lot more descriptive.


 - henrik

 --

 Visit my Blog Puppet on the Edge
 http://puppet-on-the-edge.blogspot.se/

 --
 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/lrtbji%24fqe%241%40ger.gmane.org.

 For more options, visit https://groups.google.com/d/optout.




-- 
Spencer Krum
(619)-980-7820

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

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

2014-07-25 Thread Spencer Krum

Okay. Thanks.


On Fri, Jul 25, 2014 at 5:39 AM, Henrik Lindberg 
henrik.lindb...@cloudsmith.com wrote:

 On 2014-25-07 3:32, Spencer Krum wrote:

 I'm not sure if this is the correct time to mention this, but I wonder
 if you considered arrays of hashes in decision eight?

 I guess they are not really arrays of hashes but whatever this is:

 [

'/root/file1' = {'owner' = 'root'},
'/root/file1' = {'owner' = 'nibz'},
 ]

 Right now we often use arrays of hashes with the create_resources
 function when we need to specify parameters. This is similar to the
 effect of how arrays passed into resources as title behave.

 I think it would be awesome if we could pass what we currently pass into
 create_resources into resource instantiations.


 You mean like this?

   $x = [

 '/root/file1' = {'owner' = 'root'},
 '/root/file1' = {'owner' = 'nibz'},
   ]
   file { $x: }

 When we discuss this, we preferred that the iteration is made explicit.
 You can use the same data structure, and do this:

  $x.each |$title, $attributes| { file { $title: * = $attributes } }

 Since that is much more descriptive. (In fact, that is pretty much what
 the implementation of create resources is).

 - henrik

  Thanks,
 Spencer


 On Thu, Jul 24, 2014 at 6:04 PM, Henrik Lindberg
 henrik.lindb...@cloudsmith.com mailto:henrik.lindb...@cloudsmith.com

 wrote:

 On 2014-25-07 2:32, Andy Parker wrote:

 DECISION TWO

 Resource instantiations are value producing expressions

 The expression based grammar that puppet 4 will be based on
 changed
 almost everything into a general expression, which allowed a lot
 of
 composition that wasn't possible before. This didn't change
 resource
 expressions. Resource expressions could not be assigned ($a =
 notify
 {hi:}). That is being changed. This removes several odd corners
 in the
 grammar and makes it all more consistent. It is also highly
 unlikely
 that it would be removed later (principle 1). The value of a
 resource
 expression is a reference to the created resource, or an array of
 references if there is more than one.

 QUESTION: should the value always be an array of references?
 That would
 make it much more predictable.

 DECISION THREE

 Resource instantiation expressions will not be allowed in
 dangerous
 locations

 Once resource expressions can be placed anywhere there are a few
 places
 where they would actually just do more harm than good (principle
 2). One
 example is as a parameter default (define a($b = notify {hi:})
 {}).

 DECISION FOUR

 The LHS of a resource *instantiation* expression can be an
 expression

 What?!? This means you can do:

 $a = notify
 $a { hi: }

 Once again, in clearing up odd cases in the grammar this is
 opened up to
 us. This is a very powerful feature to have available. Since this
 is
 very useful and fits well into the grammar I don't see this being
 a
 temporary thing that would then have to go away later (principle
 1).

 DECISION FIVE (how many of these are there?)

 A resource with a title of default provides the default
 parameter
 values for other resources in the same instantiation expression.

 Thanks to David Schmitt for this idea!

 Since we aren't going to change the behavior of resource default
 expressions (Notify { ... }) it seems like there needs to be
 something
 done to provide a better, safer way of specifying defaults. This
 will allow:

 notify {
   default: message = hi;
   bye: }

 The result will be a resource of type Notify with title bye and
 message
 hi. It is highly unlikely that this will go away (principle 1)
 as it is
 syntactic sugar for specifying the parameters for every resource.

 DECISION SIX

 There will be a splat operator for resource instantiation
 expressions

 To make the default resources (decision five) really useful
 there needs
 to be a way to reuse the same values across multiple defaults. The
 current, dangerous, semantics of resource default expressions
 skirt this
 issue by making defaults part of the (dynamic) evaluation scope.
 In
 order to make the default resources nearly as useful but much
 safer, we
 need to add a way to allow reuse of defaults across multiple
 resource
 instantiation expressions explicitly (principle 2).

 $owner_mode = { owner = andy, mode = '777' } # gotta make
 it secure
 file { default: *= $owner_mode;
   '/home/andy/.bashrc

Re: [Puppet-dev] how to comment and uncomment lines in a file with puppet

2014-07-24 Thread Spencer Krum

I agree with Felix.
On Jul 24, 2014 8:12 AM, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:

 On 07/24/2014 05:05 PM, Supriya Uppalapati wrote:
  *Please help me*

 While I'm not averse to that, I really think you should renew your
 inquiry to the users list. Cross-posting is frowned upon, and this is
 not a development issue.

 Best,
 Felix

 --
 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/53D1224D.9010208%40alumni.tu-berlin.de
 .
 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/CADt6FWN%3DQyWGwCbi%3DKEyW6V4gsRCG8GUgp-Mp3a2ohK%3DnRDQAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-07-24 Thread Spencer Krum

override expressions.

Just to make it clear that decision one still holds.

CONCLUSION

I think that covers it all. This will be reflected by a revert to some
code, modifying the grammar, adding some new evaluation capabilities,
including tests, and updating the specification. All of this is falling
under PUP-501, PUP-511, and PUP-2898 in some way shape or form.

This email was to record the decisions; make them public; double check
that Henrik, Joshua and I all had the same understanding of them; and
give another chance to everyone to weigh in.

I did have one question that I uncovered as I was writing this up. Some
feedback on that would be great as well.

--
Andrew Parker
a...@puppetlabs.com mailto:a...@puppetlabs.com

Freenode: zaphod42
Twitter: @aparker42
Software Developer

*Join us at PuppetConf 2014 http://www.puppetconf.com/, September
22-24 in San Francisco*
/Register by May 30th to take advantage of the Early Adopter discount
http://links.puppetlabs.com/puppetconf-early-adopter //—//save $349!/

To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANhgQXu3HVrWJrTnMgYvbY6%
3DR8B%3DvVgts2Uqmwjtj6eJRJsH7g%40mail.gmail.com
https://groups.google.com/d/msgid/puppet-dev/CANhgQXu3HVrWJrTnMgYvbY6%
3DR8B%3DvVgts2Uqmwjtj6eJRJsH7g%40mail.gmail.com?utm_medium=
emailutm_source=footer.

For more options, visit https://groups.google.com/d/optout.

Visit my Blog Puppet on the Edge
http://puppet-on-the-edge.blogspot.se/

For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

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

Re: [Puppet-dev] how to comment and uncomment lines in a file with puppet

2014-07-23 Thread Spencer Krum

You could likely use the file_line resource from the stdlib module to do
this.

On Wed, Jul 23, 2014 at 11:51 AM, Supriya Uppalapati
supriya.uppalap...@gmail.com wrote:

Other recipients:
Hi, I am trying the uncomment the lines in a file using augeas in puppet.
But it is not commenting those lines. Here is the code which I have
writen, augeas { bash_profile: context =
/home/infauser/.bash_profile, changes = [ set #comment 'ex
Hi,

I am trying the uncomment the lines in a file using augeas in puppet. But
it is not commenting those lines.

Here is the code which I have writen,

*augeas { bash_profile:context = /home/infauser/.bash_profile,
changes = [ set #comment 'export INFA_CODEPAGENAME=UTF-8', set
#comment 'export INFA_HOME=/opt/apps/Informatica/9.5.1', set
#comment 'export INFA_DOMAINS_FILE=/opt/apps/Informatica/9.5.1',],But it
is not commenting the lines. Please help me*

--
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/07d6bab6-2143-4970-8d70-d67fde9e3bd7%40googlegroups.com
https://groups.google.com/d/msgid/puppet-dev/07d6bab6-2143-4970-8d70-d67fde9e3bd7%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

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

Re: [Puppet-dev]

2014-04-06 Thread Spencer Krum

this stops the
infinite environments from appearing, it also stops the default
environment from being available.
6 Remove directory environments
- PRO: takes us back to the same behavior as has existed for several
years
thereby maintaining existing installations.
- CON: Removes the ability to enumerate environments, which is the
feature that the directory environments were created to solve.
7 Remove $environment interpolation
- PRO: This leaves only explicit environment stanzas and directory
environments, therefore no more conflicts.
- CON: completely backwards incompatible. Given that the 3.5.0
implementation of directory environments is incomplete there isn't
even a
migration for existing dynamic environment users.
8 Remove environments
- PRO: removes any kind of conflict that could happen. Simplifies the
internals of puppet considerably and resolves all environment related
bugs (such as things leaking between environments).
- CON: completely backwards incompatible. Would cause a lynch mob to
hunt
me down.
9 Create a migration script
- PRO: Would provide a way of resolving the problem and would put in
place
a better way of changing over.
- CON: many setups cannot be expressed in what is available in 3.5.0.
All
environments could be made to work, but the workflow and for users
would
have to change after they migrate.

There is a possible problem with option 4. To make directory environments
a lower
priority, there has to be some way of determining if the legacy environment
really exists. This is takes it into the relm of option 3. For instance,
if a
legacy environment is defined to not exist if none of the directories in
its
modulepath exist, then almot all setups will completely shadow directory
environments. This does allow the new directory environments to live side
by
side with dynamic environments, but not with a non-environment setup
(there is
no longer a way of having a static modulepath + directory environments,
since
the modulepath will always exist and therefore the directory environment
will
never be used).

The implementation that I have for option 4 is at
https://github.com/zaphod42/puppet/tree/issue/stable/dir-envs-collide-with-dyn-envs

I also attempted (and discarded) an implementation of option 5. Once I was
scanning uninterpolated setting values for $environment and that wasn't
fully
working I could tell that the implementation was leading to a bad
place(tm).

--
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer

*Join us at PuppetConf 2014, September 23-24 in San Francisco -
**http://puppetconf.com
http://puppetconf.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/CANhgQXtkcw6k1H54nmwPbiq3GBo_AvevtL_guCCa-DJXnULdgg%40mail.gmail.comhttps://groups.google.com/d/msgid/puppet-dev/CANhgQXtkcw6k1H54nmwPbiq3GBo_AvevtL_guCCa-DJXnULdgg%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

--
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/CADt6FWOoDgECkTQvz-8kBDYtquBk1oPG0-fMsJP%2B4P%3Dk9uw4TA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Module Team: Spring cleaning

2014-03-27 Thread Spencer Krum

This is a good idea. I'll do postgres and concat and inifile.

On Thu, Mar 27, 2014 at 6:40 PM, Daniele Sluijters
daniele.sluijt...@gmail.com wrote:

Hey everyone,

It was great seeing everyone again tonight. I was wondering if I could
minion everyone into doing something. We spent a lot of time tonight on
stale PR's, basically closing stuff that's been sitting around for a
while, is test-less or the author has fallen of the face of the planet.
What I was really hoping is that a few people could just comb through the
different modules in their own time and come up with a list for Hunter and
Ashley of stuff that should just be closed on that same basis and pass them
the PR numbers.

My hope is that in doing so we'll have more time during the next session
to actually discuss the PR's that warrant discussion and once we run out of
those have room for other topics. I'll keep combing through apt and add
mysql and firewall to my plate.

Anyone else that can take on a few modules so we can do some spring
cleaning?

--
Daniele Sluijters

--
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/f263bcb6-f165-4dfd-ace1-6280c3938429%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-dev/f263bcb6-f165-4dfd-ace1-6280c3938429%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820

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

Re: [Puppet-dev] Directory Environments

2014-02-21 Thread Spencer Krum

The new directory environments will be functional as described above,
but not feature complete in 3.5.0. The plan is to finish them in 3.6.0,
and deprecate static, dynamic and the default environment settings, which
will then be removed in 4.0.

The main directory environment feature scheduled to be added in 3.6.0
is to allow for a per environment configuration file that can customize
modulepath and manifest directory settings within each directory
environment. This would be in the form of an environment.conf file,
following the same format as puppet.conf. In addition to setting
'modulepath' and 'manifest', 'config_version' could be set here as well.
This should give parity to the current static environment sections in
puppet.conf. (https://jira.puppetlabs.com/browse/PUP-1596)

In 3.6.0, [main] 'modulepath', 'manifest', 'config_version' would be
deprecated. The default manifest would be found in
$confdir/environments/production/manifests/site.pp,
and packaging would be modified to construct this base default environment.
Use of static environment sections and interpolating $environment within
puppet.conf would be deprecated as well.

You can also enumerate the new directory environments via the v2.0 API
endpoint (/v2.0/environments) that Andy and Dan worked on. (see
https://github.com/puppetlabs/puppet/blob/master/api/docs/
http_environments.md) Command line enumeration of environments is
targeted for 4.0.

The epic for the environment work is: https://jira.puppetlabs.com/
browse/PUP-536

Please let me know if I made any mistakes about existing functionality,
or you have any questions or suggestions for us with regards to the
directory environments.

thanks,
Josh P.

--
Josh Partlow
jpar...@puppetlabs.com
Developer, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco -
http://bit.ly/pupconf14
Register now and save $350!
--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/
msgid/puppet-dev/CADxAQ5pzqpo20nuLY5LxFzrEf53V_m-8wYHNq9%2BCvo1T1b-Arw%
40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

For more options, visit https://groups.google.com/groups/opt_out.

--
Spencer Krum
(619)-980-7820

--
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/CADt6FWNm1cS_GXrsieVLtMfMZvKS7ngU14SvFC-4oud_YBrmfw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet-dev] Status of Data in modules

2013-10-11 Thread Spencer Krum

 administrators can still override it using mechanisms they're already using.

 Note too that this is the next iteration, not necessarily the end state.
 It's super important to get this right because the whole community is going
 to have to live with it for a long time; those of you out here on the
 bleeding edge willing to risk some skin to make something awesome are
 critical to making that happen.


 Totally understand the need for proof of concept, should there be
 experimental branch v.s. production branch (i.e. Linux kernel)? Would
 appreciate an official notice when a final pattern is decided for long term
 support.

 Thanks,

 Nan

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




-- 
Spencer Krum
(619)-980-7820

-- 
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] Plugin sync support for external facts

2013-09-26 Thread Spencer Krum

I feel like I should chime in on facter --puppet vs puppet facts. I run
Puppet in a nonroot environment, and I don't use the default location for
puppet.conf. As a result whenever I run puppet I also pass --config=path.
Facter, even with -p, doesn't look for a --puppet-config=path option which
means I don't get pluginsync'd facts, external or otherwise. I imagine that
a puppet fact face would properly load the puppet config file and would
help solve my problem.


On Thu, Sep 26, 2013 at 12:20 PM, Luke Kanies l...@puppetlabs.com wrote:

 On Sep 26, 2013, at 2:44 PM, Ryan Coleman r...@puppetlabs.com wrote:


 On Thu, Sep 26, 2013 at 6:45 AM, Andy Parker a...@puppetlabs.com wrote:

 Agreed, the last thing that is needed is to present a solution that we
 say is to make things easier and then have people start the simple case
 by having to learn an abstract language expressed in data structures :)

 How about a hybrid approach:

   myfacts.sh
   myfacts.meta

 where meta can still contain the description, confine, etc. However
 instead of immediately forcing the author to write s-expressions they can
 do a simplified version as you propose. That way, we can start with the
 simple equality matching (that is what a hash as the value of the confine
 means), and grow to the full expressions (which would be arrays at the
 value of the confine) if the need arises.


 I'm a little concerned about the complexity being proposed here, even in
 this slightly more reserved hybrid approach. Extending pluginsync to
 shuffle external fact scripts around seems reasonable enough but I'm
 unconvinced that it's right to add what equates to metadata for each fact
 in order to achieve it. External facts are meant to be a simple interface,
 right?

 How often would you reasonably need to confine an external fact script
 like that? At this point, what's wrong with the tiny overhead of a real
 ruby Fact?


 Also note that the original 'confine' was more about resolution mechanisms
 than facts.  That is, every OS has a different way of determining the
 hostname, so I wanted to restrict those ways to the systems on which they
 would work.

 Here we're talking about facts themselves, not different ways of
 retrieving them, so the use of confine would be changing a bit.

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




-- 
Spencer Krum
(619)-980-7820

-- 
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: 3.3 Data in Modules

2013-09-16 Thread Spencer Krum

Hi,

I have to run to work, but quickly here is my binder_config.yaml

root@hiera-2:/etc/puppet# cat hiera.yaml
---
version: 2
hierarchy:
[ ['osfamily', '${osfamily}', '${osfamily}' ],
['environment', '${environment}', '${environment}' ],
['common', 'true', 'common' ]
]
backends:
- yaml
- json

I'll copy in the new one after work and see if I can get it working.

I have been using calling scope variables in my hiera lookups. I use a
$cname variable set at node scope to allow machines to get their ssl certs
out of hiera. How could I implement this under the new system?

Thanks for replying so quickly,
Spencer

On Mon, Sep 16, 2013 at 8:12 AM, Henrik Lindberg
henrik.lindb...@cloudsmith.com wrote:

On 2013-16-09 3:39, Spencer Krum wrote:

Hello,

I am trying to follow ARM-9 and use the data in modules features
introduced in the 3.3 release. I am struggling to get many of the
features mentioned in ARM-9 working. I have a basic module here
https://github.com/pro-puppet/**puppet-module-startrekhttps://github.com/pro-puppet/puppet-module-startrek,
but when trying to
add an element to the hierarchy (see branch 'species') I'm hitting a
roadblock. I have copied in the binder_config.yaml file from ARM-9, even
without modifications, and I get the following error:

root@hiera-2:/etc/puppet# !pup
puppet apply modules/startrek/tests/init.pp
Error: syntax error on line 3, col 20: ` { 'name' = 'site',' on node
hiera-2.green.gah
Error: syntax error on line 3, col 20: ` { 'name' = 'site',' on node
hiera-2.green.gah

So I guess my immediate question is is the binder_config.yaml snippet
in ARM-9 correct?

The typos (backslashes in examples) are now removed in the ARM-9 text.

Thanks again for catching this and reporting.

- henrik

--
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.compuppet-dev%2bunsubscr...@googlegroups.com
.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at
http://groups.google.com/**group/puppet-devhttp://groups.google.com/group/puppet-dev
.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
Spencer Krum
(619)-980-7820

--
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: 3.3 Data in Modules

2013-09-16 Thread Spencer Krum

Hi Henrik, and others,

How does a google hangout at 11am tomorrow work? Myself, Danny, and William
Van Hevelingen can all be available at that time.

Thanks,
Spencer

On Mon, Sep 16, 2013 at 9:15 AM, Spencer Krum krum.spen...@gmail.comwrote:

Hi,

I have to run to work, but quickly here is my binder_config.yaml

I'll copy in the new one after work and see if I can get it working.

Thanks for replying so quickly,
Spencer

On Mon, Sep 16, 2013 at 8:12 AM, Henrik Lindberg
henrik.lindb...@cloudsmith.com wrote:

On 2013-16-09 3:39, Spencer Krum wrote:

Hello,

So I guess my immediate question is is the binder_config.yaml snippet
in ARM-9 correct?

The typos (backslashes in examples) are now removed in the ARM-9 text.

Thanks again for catching this and reporting.

- henrik

--
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.compuppet-dev%2bunsubscr...@googlegroups.com
.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at
http://groups.google.com/**group/puppet-devhttp://groups.google.com/group/puppet-dev
.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
Spencer Krum
(619)-980-7820

--
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: 3.3 Data in Modules

2013-09-16 Thread Spencer Krum

Okay, lets do that.


On Mon, Sep 16, 2013 at 8:41 PM, Henrik Lindberg 
henrik.lindb...@cloudsmith.com wrote:

 On 2013-16-09 19:57, Spencer Krum wrote:

 Hi Henrik, and others,

 How does a google hangout at 11am tomorrow work? Myself, Danny, and
 William Van Hevelingen can all be available at that time.

  Depends on which Timezone you are in :-)

 I am available Tuesday 17 Sept PDT 6am - PDT 8pm (give or take breaks) -
 so if that was 11am PDT, you can count me in. I am
 henrik.lindb...@puppetlabs.com on google+

 Regards
 - henrik

  Thanks,
 Spencer


 On Mon, Sep 16, 2013 at 9:15 AM, Spencer Krum krum.spen...@gmail.com
 mailto:krum.spen...@gmail.com** wrote:

 Hi,

 I have to run to work, but quickly here is my binder_config.yaml

 root@hiera-2:/etc/puppet# cat hiera.yaml
 ---
 version: 2
 hierarchy:
[ ['osfamily', '${osfamily}', '${osfamily}' ],
  ['environment', '${environment}', '${environment}' ],
  ['common', 'true', 'common' ]
]
 backends:
- yaml
- json

 I'll copy in the new one after work and see if I can get it working.

 I have been using calling scope variables in my hiera lookups. I use
 a $cname variable set at node scope to allow machines to get their
 ssl certs out of hiera. How could I implement this under the new
 system?

 Thanks for replying so quickly,
 Spencer


 On Mon, Sep 16, 2013 at 8:12 AM, Henrik Lindberg
 henrik.lindberg@cloudsmith.**com henrik.lindb...@cloudsmith.com
 
 mailto:henrik.lindberg@**cloudsmith.comhenrik.lindb...@cloudsmith.com
 wrote:

 On 2013-16-09 3:39, Spencer Krum wrote:

 Hello,

 I am trying to follow ARM-9 and use the data in modules
 features
 introduced in the 3.3 release. I am struggling to get many
 of the
 features mentioned in ARM-9 working. I have a basic module
 here
 
 https://github.com/pro-puppet/**__puppet-module-startrekhttps://github.com/pro-puppet/__puppet-module-startrek
 
 https://github.com/pro-**puppet/puppet-module-startrekhttps://github.com/pro-puppet/puppet-module-startrek
 **, but

 when trying to
 add an element to the hierarchy (see branch 'species') I'm
 hitting a
 roadblock. I have copied in the binder_config.yaml file from
 ARM-9, even
 without modifications, and I get the following error:

 root@hiera-2:/etc/puppet# !pup
 puppet apply modules/startrek/tests/init.pp
 Error: syntax error on line 3, col 20: `  { 'name' =
 'site',' on node
 hiera-2.green.gah
 Error: syntax error on line 3, col 20: `  { 'name' =
 'site',' on node
 hiera-2.green.gah

 So I guess my immediate question is is the
 binder_config.yaml snippet
 in ARM-9 correct?


 The typos (backslashes in examples) are now removed in the ARM-9
 text.

 Thanks again for catching this and reporting.

 - henrik



 --
 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@__googl**egroups.comhttp://googlegroups.com
 
 mailto:puppet-dev%**2bunsubscr...@googlegroups.compuppet-dev%252bunsubscr...@googlegroups.com
 **.

 To post to this group, send email to puppet-dev@googlegroups.com
 mailto:puppet-dev@**googlegroups.compuppet-dev@googlegroups.com
 .
 Visit this group at 
 http://groups.google.com/__**group/puppet-devhttp://groups.google.com/__group/puppet-dev
 
 http://groups.google.com/**group/puppet-devhttp://groups.google.com/group/puppet-dev
 .
 For more options, visit
 
 https://groups.google.com/__**groups/opt_outhttps://groups.google.com/__groups/opt_out
 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .




 --
 Spencer Krum
 (619)-980-7820 tel:%28619%29-980-7820





 --
 Spencer Krum
 (619)-980-7820

 --
 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.compuppet-dev%2bunsubscr...@googlegroups.com
 .
 To post to this group, send email to puppet-dev@googlegroups.com.
 Visit this group at 
 http://groups.google.com/**group/puppet-devhttp://groups.google.com/group/puppet-dev
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .



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

[Puppet-dev] 3.3 Data in Modules

2013-09-15 Thread Spencer Krum

Hello,

I am trying to follow ARM-9 and use the data in modules features introduced 
in the 3.3 release. I am struggling to get many of the features mentioned 
in ARM-9 working. I have a basic module here 
https://github.com/pro-puppet/puppet-module-startrek, but when trying to 
add an element to the hierarchy (see branch 'species') I'm hitting a 
roadblock. I have copied in the binder_config.yaml file from ARM-9, even 
without modifications, and I get the following error:

root@hiera-2:/etc/puppet# !pup
puppet apply modules/startrek/tests/init.pp 
Error: syntax error on line 3, col 20: `  { 'name' = 'site',' on node 
hiera-2.green.gah
Error: syntax error on line 3, col 20: `  { 'name' = 'site',' on node 
hiera-2.green.gah

So I guess my immediate question is is the binder_config.yaml snippet in 
ARM-9 correct? is there an error in it somewhere? and my larger question 
is where are the full examples of how to do use this? I doubt that all this 
code was developed without simple testing modules being built alongside it 
to test features.

Third, it says in ARM-9 that all lookups are performed using topscope. Does 
that mean we no longer have access to variables set at local scope when we 
do our lookup?

Finally, if this is not the place to post these kinds of questions please 
tell me where to do so.

Thanks,
Spencer

-- 
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: Thoughts on Module Namespace Conflicts

Re: [Puppet-dev] [announce] beaker-rspec 5.2.0 released

Re: [Puppet-dev] Validation Resources

[Puppet-dev] Validation Resources

Re: [Puppet-dev] Validation Resources

Re: [Puppet-dev] Re: Thoughts on Module Namespace Conflicts

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

Re: [Puppet-dev] Beaker-extensions

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

Re: [Puppet-dev] Re: zpool mirror and raidz virtual devices

Re: [Puppet-dev] zpool mirror and raidz virtual devices

Re: [Puppet-dev] Re: Leaving Puppet Labs

Re: [Puppet-dev] Switching from YAML and PSON to JSON

Re: [Puppet-dev] Abusing PuppetDB

Re: [Puppet-dev] Statistics for Modules

Re: [Puppet-dev] Statistics for Modules

[Puppet-dev] Statistics for Modules

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

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

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

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

Re: [Puppet-dev] how to comment and uncomment lines in a file with puppet

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

Re: [Puppet-dev] how to comment and uncomment lines in a file with puppet

Re: [Puppet-dev]

Re: [Puppet-dev] Module Team: Spring cleaning

Re: [Puppet-dev] Directory Environments

Re: [Puppet-dev] Status of Data in modules

Re: [Puppet-dev] Plugin sync support for external facts

Re: [Puppet-dev] Re: 3.3 Data in Modules

Re: [Puppet-dev] Re: 3.3 Data in Modules

Re: [Puppet-dev] Re: 3.3 Data in Modules

[Puppet-dev] 3.3 Data in Modules

33 matches

Site Navigation

Mail list logo

Footer information