Jonathan Furrer | 4 Sep 21:27 2007

Re: [Puppet-dev] [Puppet-users] Puppet Documentation

Hi guys, I'd like some feedback on a patch I'm about to write. The yum provider for package does not currently support the use of yum's --installroot=blah option. I need it to. One of the things I've run into while creating my patch was that because the name of the package is taken from the name of the resource, I was limited to installing a package to only one root.

In my environment I've corrected that by adding two new attributes to the package type. 1) installroot, which if present adds --installroot=value to yum calls and --root=value to rpm calls) and 2) package, which if not specified is set to name. I then made everywhere that yum/rpm use <at> model[name] use <at> model[package].

It works really well, the feedback I'm asking for is regarding whether or not this is deemed as an appropriate way to pull it off. It's a reasonable change to an existing type but I'm a just a system engineer...not a developer per say :) If you guys agree with my method, I'll create a diff patch against what's in svn and submit it.

This would be the first time I've really ever contributed to a open source project, so I'm not 100% sure how to continue.

--
Jon

_______________________________________________
Puppet-dev mailing list
Puppet-dev <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-dev
Luke Kanies | 5 Sep 01:08 2007

[Puppet-dev] Specifying class/definition version

Hi all,

For a client, I'm implementing the ability to specify a class or  
definition version, and then require a specific class or definition  
with a specific version.

The 'require' part is pretty easy -- just create a new function that  
accepts an optional version parameter:

class yay {
   require boo, "1.0"
}

This would be a superset of 'include', in that it would find the  
class, verify the version, and if the version was valid then it would  
call 'include', else it would throw an exception.

The problem comes in how to specify the version.  My first thought  
was to create a 'version' keyword:

class boo {
   version "1.0"
}

The problem with this is that it would have to be evaluated parse- 
time, not compile-time, so that you could evaluate whether a class is  
the right version before you actually evaluated the class itself.  I  
just took a look at the grammar, and doing this would require quite a  
bit of nastiness that I wouldn't want to have to deal with, and I  
think people would be surprised to find that 'version' didn't support  
interpolated variables or the like.

So, I'm leaning toward putting the version number in the prototype,  
something like this:

class boo is "1.0" {
}

or:

class boo inherits other is "1.0" {
}

Definitions could declare versions, too, I suppose:

define me($var) is "1.0" {
}

I don't particularly like this, but I also don't see much in the way  
of other options.

Comments?

  --
  If you would be a real seeker after truth, it is necessary that at
  least once in your life you doubt, as far as possible, all things.
          -- Rene Descartes
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com
Matthew Palmer | 5 Sep 02:03 2007

Re: [Puppet-dev] Specifying class/definition version

On Tue, Sep 04, 2007 at 06:08:05PM -0500, Luke Kanies wrote:
> For a client, I'm implementing the ability to specify a class or  
> definition version, and then require a specific class or definition  
> with a specific version.

[...]

> Comments?

What is the exact problem you're trying to solve, and what other possible
solutions have you examined and rejected, and why?

- Matt
James Turnbull | 5 Sep 02:10 2007
Picon

Re: [Puppet-dev] Specifying class/definition version

> class boo is "1.0" {
> }
> 
> or:
> 
> class boo inherits other is "1.0" {
> }
> 
> Definitions could declare versions, too, I suppose:
> 
> define me($var) is "1.0" {
> }
> 
> I don't particularly like this, but I also don't see much in the way  
> of other options.
> 

The former is obviously more in line with the rest of the grammar but I
can understand why it might be messy.  The latter isn't overly elegant.

What exactly is the client's requirement?

Regards

James Turnbull

--

-- 
James Turnbull <james <at> lovedthanlost.net>
---
Author of Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)

Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)

_______________________________________________
Puppet-dev mailing list
Puppet-dev <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-dev
David Schmitt | 5 Sep 08:24 2007
Picon

Re: [Puppet-dev] Specifying class/definition version


On Wednesday 05 September 2007, Luke Kanies wrote:
> Hi all,
>
> For a client, I'm implementing the ability to specify a class or
> definition version, and then require a specific class or definition
> with a specific version.

[...]

> I don't particularly like this, but I also don't see much in the way
> of other options.
>
> Comments?

class boo_1 { }
define muh_1() { }

or even

class boo::v1 { }
define muh::v1() { }

If you need the ability to get a "default" version too, you can just have 

class boo::default inherits boo::v1 { }

somewhere. 

See also "Pounding A Nail: Old Shoe or Glass Bottle?" 
http://weblogs.asp.net/alex_papadimoulis/archive/2005/05/25/408925.aspx

Regards, David
--

-- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
-- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
Luke Kanies | 5 Sep 17:59 2007

Re: [Puppet-dev] [Puppet-users] Puppet Documentation

On Sep 4, 2007, at 2:27 PM, Jonathan Furrer wrote:

> Hi guys, I'd like some feedback on a patch I'm about to write. The  
> yum provider for package does not currently support the use of  
> yum's --installroot=blah option. I need it to. One of the things  
> I've run into while creating my patch was that because the name of  
> the package is taken from the name of the resource, I was limited  
> to installing a package to only one root.
>
> In my environment I've corrected that by adding two new attributes  
> to the package type. 1) installroot, which if present adds -- 
> installroot=value to yum calls and --root=value to rpm calls) and  
> 2) package, which if not specified is set to name. I then made  
> everywhere that yum/rpm use  <at> model[name] use  <at> model[package].

Note that the variable ' <at> model' changed to ' <at> resource' in 0.23,  
making it more consistent with the rest of the system.

> It works really well, the feedback I'm asking for is regarding  
> whether or not this is deemed as an appropriate way to pull it off.  
> It's a reasonable change to an existing type but I'm a just a  
> system engineer...not a developer per say :) If you guys agree with  
> my method, I'll create a diff patch against what's in svn and  
> submit it.

I don't understand the need for the 'package' parameter -- does it  
allow you to have a different name so that, say, you can have the  
same package installed in both the normal root and the separate  
root?  If not, what's it for?

Otherwise, it seems fine to me.  And I started out as a sysadmin  
providing patches to open source projects, so we're happy to have  
another. :)

> This would be the first time I've really ever contributed to a open  
> source project, so I'm not 100% sure how to continue.

Exactly like this, although use git instead of svn.  Here's the only  
page we have on it right now:  https://reductivelabs.com/trac/puppet/ 
wiki/SubversionToGitOrDarcs

I'll be switching the docs today, though.

  --
  Trying to determine what is going on in the world by reading  
newspapers
  is like trying to tell the time by watching the second hand of a  
clock.
          --Ben Hecht
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com
Udo Waechter | 5 Sep 18:44 2007
Picon
Picon

Re: [Puppet-dev] [Puppet-users] Puppet Documentation

Hello,
this patch would be a nice feature for the appdmg provider for Darwin. 
Then, one could install application bundles in other places than the 
default /Applications.
Bye,
udo.
Luke Kanies wrote:
> On Sep 4, 2007, at 2:27 PM, Jonathan Furrer wrote:
> 
>> Hi guys, I'd like some feedback on a patch I'm about to write. The  
>> yum provider for package does not currently support the use of  
>> yum's --installroot=blah option. I need it to. One of the things  
>> I've run into while creating my patch was that because the name of  
>> the package is taken from the name of the resource, I was limited  
>> to installing a package to only one root.
>>
>> In my environment I've corrected that by adding two new attributes  
>> to the package type. 1) installroot, which if present adds -- 
>> installroot=value to yum calls and --root=value to rpm calls) and  
>> 2) package, which if not specified is set to name. I then made  
>> everywhere that yum/rpm use  <at> model[name] use  <at> model[package].
> 
> Note that the variable ' <at> model' changed to ' <at> resource' in 0.23,  
> making it more consistent with the rest of the system.
> 
>> It works really well, the feedback I'm asking for is regarding  
>> whether or not this is deemed as an appropriate way to pull it off.  
>> It's a reasonable change to an existing type but I'm a just a  
>> system engineer...not a developer per say :) If you guys agree with  
>> my method, I'll create a diff patch against what's in svn and  
>> submit it.
> 
> I don't understand the need for the 'package' parameter -- does it  
> allow you to have a different name so that, say, you can have the  
> same package installed in both the normal root and the separate  
> root?  If not, what's it for?
> 
> Otherwise, it seems fine to me.  And I started out as a sysadmin  
> providing patches to open source projects, so we're happy to have  
> another. :)
> 
>> This would be the first time I've really ever contributed to a open  
>> source project, so I'm not 100% sure how to continue.
> 
> Exactly like this, although use git instead of svn.  Here's the only  
> page we have on it right now:  https://reductivelabs.com/trac/puppet/ 
> wiki/SubversionToGitOrDarcs
> 
> I'll be switching the docs today, though.
> 
>   --
>   Trying to determine what is going on in the world by reading  
> newspapers
>   is like trying to tell the time by watching the second hand of a  
> clock.
>           --Ben Hecht
>   ---------------------------------------------------------------------
>   Luke Kanies | http://reductivelabs.com | http://madstop.com
> 
> 
> _______________________________________________
> Puppet-dev mailing list
> Puppet-dev <at> madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-dev
> 
Jonathan Furrer | 5 Sep 19:01 2007

Re: [Puppet-dev] [Puppet-users] Puppet Documentation

The reason for using the package attribute is exactly as you said, so that the resource name can be independent of the package name in cases where I have the same package in root and a unique root.

Thanks for the gotcha, when I pull the latest source to create the patch against (I'm running an older version with my patch currently)  I'll make sure I get that correct.

On 9/5/07, Luke Kanies <luke <at> madstop.com> wrote:
On Sep 4, 2007, at 2:27 PM, Jonathan Furrer wrote:

> Hi guys, I'd like some feedback on a patch I'm about to write. The
> yum provider for package does not currently support the use of
> yum's --installroot=blah option. I need it to. One of the things
> I've run into while creating my patch was that because the name of
> the package is taken from the name of the resource, I was limited
> to installing a package to only one root.
>
> In my environment I've corrected that by adding two new attributes
> to the package type. 1) installroot, which if present adds --
> installroot=value to yum calls and --root=value to rpm calls) and
> 2) package, which if not specified is set to name. I then made
> everywhere that yum/rpm use <at> model[name] use <at> model[package].

Note that the variable ' <at> model' changed to ' <at> resource' in 0.23,
making it more consistent with the rest of the system.

> It works really well, the feedback I'm asking for is regarding
> whether or not this is deemed as an appropriate way to pull it off.
> It's a reasonable change to an existing type but I'm a just a
> system engineer...not a developer per say :) If you guys agree with
> my method, I'll create a diff patch against what's in svn and
> submit it.

I don't understand the need for the 'package' parameter -- does it
allow you to have a different name so that, say, you can have the
same package installed in both the normal root and the separate
root?  If not, what's it for?

Otherwise, it seems fine to me.  And I started out as a sysadmin
providing patches to open source projects, so we're happy to have
another. :)

> This would be the first time I've really ever contributed to a open
> source project, so I'm not 100% sure how to continue.

Exactly like this, although use git instead of svn.  Here's the only
page we have on it right now:  https://reductivelabs.com/trac/puppet/
wiki/SubversionToGitOrDarcs

I'll be switching the docs today, though.

  --
  Trying to determine what is going on in the world by reading
newspapers
  is like trying to tell the time by watching the second hand of a
clock.
          --Ben Hecht
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com


_______________________________________________
Puppet-dev mailing list
Puppet-dev <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-dev




--
Jon
_______________________________________________
Puppet-dev mailing list
Puppet-dev <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-dev
Luke Kanies | 5 Sep 20:13 2007

Re: [Puppet-dev] Relocating packages (was: Puppet Documentation)

On Sep 5, 2007, at 12:01 PM, Jonathan Furrer wrote:

> The reason for using the package attribute is exactly as you said,  
> so that the resource name can be independent of the package name in  
> cases where I have the same package in root and a unique root.

I can't decide whether this is a good thing or bad.  It certainly  
brings us right back to the problem of supporting resources that have  
multiple primary keys; in this case, we'd want to consider a package  
to be uniquely identified by its name and install root, I guess,  
assuming that package listing can handle that for us.

What do others think?

> Thanks for the gotcha, when I pull the latest source to create the  
> patch against (I'm running an older version with my patch  
> currently)  I'll make sure I get that correct.

Okay.  I'm nearly done switching all of the docs to mention Git  
instead of SVN, FWIW.

I've also switched Facter to using git instead of svn.

  --
  I went to a restaurant that serves "breakfast at anytime".  So I
  ordered French Toast during the Renaissance.     -- Stephen Wright
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies | 5 Sep 22:14 2007

Re: [Puppet-dev] Specifying class/definition version

On Sep 4, 2007, at 7:03 PM, Matthew Palmer wrote:

> What is the exact problem you're trying to solve, and what other  
> possible
> solutions have you examined and rejected, and why?

Sorry for the delayed response, but I was asking myself the same  
question and have now gotten more information from the client.

The problem I was specifically trying to solve is one of  
compatibility -- how do you declare that classA is only compatible  
with specific versions of classB?  I'm calling this the  
'compatibility problem'.

However, in talking to the client, they are more interested in  
solving a general change control problem -- how do you handle  
transitioning a set of systems from one version of a class to  
another, in a situation where you are guaranteed to need to run both  
versions concurrently on separate hosts?   I'm calling this the  
'transition state problem'.

I'm thinking that the compatibility problem is actually best solved  
at the module level rather than the class level, although then it  
starts to smell a lot like a packaging problem.

The transition state problem, I think, is a much, much larger  
problem, and it sits squarely in the change management world.  I have  
some ideas for this, but I think I'll have to save those for a  
separate post (or, more likely, an enhancement request and associated  
spec on the wiki).

In the meantime, I'm going to go back to focusing on the REST  
conversion, with the goal of having it released in September, with  
any necessary open bug tickets fixed.  During that time, I'll plan on  
coming up with a design to solve the compatibility problem, and at  
least fully spec'ing the transition state problem, if not yet coming  
up with a solution.

  --
  Think twice before you speak, and then you may be able to say  
something
  more insulting than if you spoke right out at once.     - Evan Esar
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Gmane